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A mi esposa, que me ha importunado para que terminara; 
mi amiga, que me ha levantado el ánimo; 
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A la persona única en que se reúnen todas éstas. 


EL FORASTERO: Por favor, ¿por dónde puedo ir a Correos? 
EL NATIVO: Si yo tuviera que ir a Correos, no empezaría desde aquí. 


Prefacio 


Este libro parte de la suposición de que sus lectores son programadores ra- 
zonablemente competentes en BASIC, y que desean aprender PASCAL. La 
mayoría de los libros de PASCAL parecen escritos para lectores totalmente 
carentes de cualquier noción de programación. Sin embargo, tu problema es 
distinto del de un novato. No necesitas que se te expliquen conceptos básicos, 
como los de variables, bucles, etc.; lo que necesitas es que se te ayude par adaptar 
tu forma de pensar desde el BASIC al PASCAL. En realidad, la tarea a la 
que te enfrentas es probablemente más ardua que la del novato, porque el BA- 
SIC es en realidad un elemento heterodoxo e insolidario entre todos los len- 
guajes de programación... aunque, a pesar de ello (o, tal vez, por ello mismo), 
se ha convertido en el lenguaje más popular del mundo. Es más difícil apren- 
der unos conceptos, y luego volver a aprenderlos de nuevo en una forma dife- 
rente, que empezar completamente desde cero. No lo dudes, el paso desde el 
BASIC al PASCAL supone un cambio drástico. Si escribes tus programas en 
PASCAL en la misma forma que tus programas en BASIC, te parecerás a un 
turista inglés en Francia traduciendo sus frases, palabra por palabra, con la 
ayuda de un diccionario. 

Lo que este libro pretende especificamente es ayudarte a superar los pro- 
blemas que los programadores en BASIC encuentran en el PASCAL, y a reali- 
zar la consiguiente adaptación en tu estilo de programar. No suponemos que 
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vayas a decir adiós para siempre a tu viejo amigo el BASIC. En realidad, nues- 
tro libro se muestra bastante crítico acerca de determinados aspectos del PAS- 
CAL, y trata de exponer claramente al lector aquellas cosas en las que el PAS- 
CAL gana, y las otras en las que pierde. 

Tratamos también de mantener en esta obra un tono ligero, que haga su 
lectura divertida. Nuestro objetivo es la seriedad, pero sin solemnidad ni pesa- 
dez. Los conceptos se van introduciendo casi exclusivamente con ayuda de ejem- 
plos que, cuando ello conviene, se relacionan o comparan con el BASIC. Si 
prefieres un enfoque o un tratamiento más formal o estirado, busca en otra 
parte. 

Cuando hayas leído el libro, deberás haber adquirido dos capacidades. De- 
berás ser capaz de escribir buenos programas en PASCAL, y también de leer 
libros o manuales referentes a dicho lenguaje y entender lo que tratan. 

Este libro mantiene una exquisita neutralidad respecto a las distintas ver- 
siones de PASCAL que compiten entre sí: con una honradez absoluta, no men- 
ciona a ninguna de ellas. Afortunadamente, los distintos sistemas de PASCAL 
se parecen mucho más entre sí que los distintos sistemas de BASIC, de modo 
que es posible dar una descripción detallada sin que ello implique comprome- 
terse con una implementación concreta o determinada. Así, por ejemplo, im- 
porta poco si piensas usar el PASCAL en un ordenador personal o en una gran 
unidad central utilizada en tiempo compartido. 


Reconocimientos 
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Comienza en el comienzo. 


DYLAN THOMAS 


Un ejemplo 
para enseñar 
los fundamentos 


Un ejemplo 


Para ir haciéndonos una idea de la tarea que tenemos ante nosotros, empe- 
zaremos con un programa BASIC muy sencillo y mostraremos su equivalente 
en PASCAL. EL programa toma como datos un número N, al que siguen otros 
N números. Todo lo que realiza el programa es imprimir la media aritmética 
de los mismos. En BASIC, este programa se puede escribir así: 


10. REM-——HALLAR LA MEDIA ARITMETICA 
DE N NUMEROS-——— 

100. INPUT N 

110 LETS=0 

120 FORK = 1 TON 

130 INPUT X 

140 LETS =S+X 

150 NEXT K 

200 PRINT. “MEDIA =>”;¡S/N 

999 END 
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Una traducción directa de esto en PASCAL —que, como veremos, no es 
un buen programa PASCAL— es la siguiente: 


program mediaaritméticalinput, output); 
(x* halla la media aritmética de N números +) 
var 
: integer; 
: integer; 
real; 
: real; 
begin 
read(n); 
s:=0; 
for k:=1 to n do 
begin 
read(x); 
S=S+X; 
end; 
writeln (Mediaaritmética =?, s/n); 
end. 


an *-= 


Si no habías visto hasta ahora un programa PASCAL, te llamarán inme- 
diatamente la atención muchas diferencias con respecto al BASIC. 

La más patente es, paradójicamente, una de las menos importantes: el he- 
cho de que el programa en BASIC emplee letras mayúsculas, mientras que el 
PASCAL utiliza minúsculas. Lo primero que hay que decir es que se trata en 
gran medida de una cuestión de costumbre, no de necesidad. Podríamos haber 
escrito el programa BASIC en minúsculas y el PASCAL en mayúsculas, y los 
programas seguirían siendo aceptables para la mayoría de los compiladores. 

El hábito —y no es un hábito universal— de usar letras mayúsculas en BA- 
SIC es, en buena medida, resultado de la historia. El BASIC se desarrolló a 
comienzos de la década de los sesenta, cuando los ordenadores tenían unos 
juegos de caracteres muy pequeños; las entradas a los ordenadores se hacían 
frecuentemente desde tarjetas perforadas o máquinas de escribir bastante pri- 
mitivas, y a menudo no se disponía de letras minúsculas. En épocas más re- 
cientes, tanto los ordenadores como los dispositivos desde los que se pueden 
introducir datos en ellos han sido dotados de juegos de caracteres más ricos. 
Ahora ya no tenemos que GRITAR AL ORDENADOR EN LETRAS MA- 
YUSCULAS, sino que podemos comunicarnos en minúsculas de un modo mu- 
cho más refinado. La oscilación del péndulo ha llegado ahora tan lejos que 
muchos programadores evitan totalmente el uso de las mayúsculas, y los ma- 
nuales de programación para los lenguajes más recientes tienden a hacer lo mis- 
mo. Seguramente el péndulo volverá algún día a ocupar una posición más mo- 
derada. 

No obstante, la convención actual nos resulta bastante útil para este libro. 
Presentaremos en él los programas de BASIC en mayúsculas y los de PAS- 


CAL en minúsculas. Ello nos permitirá hablar de los programas y establecer 
comparaciones entre ellos sin riesgo alguno de ambigiiedad. 

Puede verse también que los programas en PASCAL contienen palabras 
en negrita, por ejemplo begin. También esto es un hábito o costumbre de pre- 
sentación más que una propiedad del lenguaje. Cuando el programa se introdu- 
ce en el ordenador desde el teclado, las letras negritas se escriben como letras 
ordinarias. 


Declaraciones 


Una segunda faceta llamativa de los programas es que en BASIC la acción 
empieza ya desde la primera línea (o, estrictamente hablando, desde la segun- 
da, ya que la primera es un comentario), mientras que en el programa de PAS- 
CAL hay media docena de líneas de introducción antes de que realmente em- 
piece a ocurrir algo. La primera línea es 


program mediaaritméticalinput, output); 


Al principio de todo programa PASCAL ha de venir una línea de esta for- 
ma, en la que aparezca el nombre que elijamos para el programa, en este caso 
mediaaritmética. Más adelante explicaremos esta línea de encabezamiento del 
programa. La línea que sigue al encabezamiento es un comentario PASCAL, se- 
mejante a una sentencia REM en BASIC. 

Mucho más importantes son las líneas 


var 
: integer; 
: integer; 
real; 
real; 


n>”=> 


Estos son ejemplos de declaraciones. En BASIC, si queremos usar una va- 
riable X podemos hacerlo sin preparativos ni ruido alguno; en PASCAL, en 
cambio, tenemos que declarar la variable X antes de poder usarla. El BASIC, 
desde luego, incluye el concepto de las declaraciones. Si en BASIC queremos 
usar una matriz o array (una tabla) Q, tenemos que declararla por medio de 
una línea tal como 


DIM Q 6, 8) 
En el PASCAL existe la misma idea, pero hay que declararlo todo. 
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Cuando declaramos una variable, tenemos que especificar su fipo de da- 
tos. Esto de los tipos de datos constituye uno de los rasgos más potentes y ex- 
citantes del PASCAL, aunque ello no quede de manifiesto en nuestro presente 
ejemplo de programa. El PASCAL tiene ya incorporados algunos tipos de da- 
tos, como los tipos integer y real utilizados en el ejemplo, y nos permite tam- 
bién definir nuestros propios tipos, como se verá más adelante. En el BASIC 
existe ya la idea embrionaria del tipo de datos. Las variables son normalmente 
del tipo de datos numérico, como las N, K, S y X en nuestro ejemplo. Sin em- 
bargo, si se añade el símbolo de dólares al nombre de una variable, ésta es 
del tipo de datos de string, o cadena de caracteres, por ejemplo, A$, P9$. Al- 
gunos lenguajes BASIC emplean también un tipo de datos integer o entero, 
que frecuentemente se representa por nombres tales como KY%, TW. 

El tipo de datos especifica el juego o conjunto de valores que puede tomar 
un objeto. Con cada tipo de datos va asociado un conjunto de operadores; 
por ejemplo, podemos aplicar un operador multiplicador a los datos numéri- 
cos. No es posible multiplicar entre sí dos literales o cadenas de caracteres, pe- 
ro existen otras operaciones que se aplican únicamente a las cadenas, tales co- 
mo la extracción de una subcadena (substring). Algunos operadores son poli- 
mórficos, en cuanto que se pueden aplicar a más de un tipo de datos. En BA- 
SIC, por ejemplo, ocurre esto con el operador de asignación y con algunos 
operadores en sentencias IF, por ejemplo: 


LET X = 3 
LET X$ = “STRING” 


IF X = Y THEN 30 
IF X$ = Y$ THEN 50 


Al PASCAL le son aplicables reglas similares. Los tipos de datos del BA- 
SIC se ponen de manifiesto por el nombre de la variable: X es numérica, y 
X$ es una cadena. En PASCAL se puede utilizar cualquier nombre para cual- 
quier variable. Cuando declaramos la variable damos su nombre y el tipo de 
datos asociado con ella. Más adelante veremos que en los nombres del PAS- 
CAL existe libertad de elección. En lugar del nombre s podríamos haber usa- 
do (en realidad, deberíamos haberlo hecho) el nombre suma o incluso suma- 
devariables. Como principio general, lo mejor es elegir nombres que manifies- 
ten claramente el objeto o finalidad de las variables; si hemos utilizado estos 
nombres formados por una sola letra, ha sido para mantener una correspon- 
dencia directa con el BASIC. 

Los tipos de datos utilizados en el programa de mediaaritmética son reales 
(real), lo que equivale al tipo numérico del BASIC, y enteros (integer). De las 
variables s y x se declara que son variables reales, y de las n y k, que son varia- 
bles enteras o integer. (Podríamos haber escrito estas cuatro declaraciones en 
cualquier orden, lo mismo que en BASIC las cadenas o strings se pueden decla- 
rar en cualquier orden.) En PASCAL es importante distinguir aquellas varia- 
bles que sólo pueden tomar valores enteros, como la k y la n en el programa 
de mediaaritmética, de aquellas que pueden tomar cualquier valor numérico, 


como las s y x. Las razones para ello se desprenden principalmente del diseño 
de los ordenadores actuales. Si se sabe que una variable toma solamente valo- 
res enteros, es posible almacenarla en una forma distinta y más compacta que 
la de una variable que pueda adoptar cualquier valor numérico. Además, las 
Operaciones realizadas con enteros se ejecutan a una velocidad mucho mayor 
que las hechas con valores reales; esta relación de velocidades puede variar desde 
dos a más de cien. Finalmente, las operaciones con enteros son exactas. Las 
Operaciones con variables reales son inexactas y pueden dar pequeños errores 
de redondeo. Es muy posible que hayas experimentado los efectos de ese re- 
dondeo al ejecutar un programa de BASIC; tal vez esperaras que el resultado 
de un programa fuera 6 y, en lugar de ello, hayas obtenido como resultado 
6,000000001. 

En la mayoría de los lenguajes BASIC, se hace caso omiso de la diferencia 
entre números enteros y reales, haciendo a todos reales (numéricos), y uno se 
aguanta con las ocasionales excentricidades, tales como la del 6,000000001. En 
PASCAL algunas veces es posible hacer esto sin que pase nada, pero no se 
puede usar una variable real en una sentencia for o como subíndice de una 
matriz o array. Dadas estas exigencias y sus consecuencias indirectas, lo mejor 
es distinguir los números enteros de los reales. El único problema que puede 
surgir cuando se usa el tipo de datos integer o enteros es que algunas imple- 
mentaciones imponen unos límites bastante severos sobre el valor de los ente- 
ros. Por ejemplo, pueden estar prohibidos éstos por encima de 32.767. Para 
más detalles, consulta tu manual particular. 


El programa 


Al mirar las instrucciones ejecutables del programa PASCAL, te hallarás 
en un terreno más familiar. Las sentencias del ejemplo de PASCAL se corres- 
ponden una por una con las del ejemplo de BASIC, si se exceptúa el hecho 
de que el PASCAL incluya un par de begin y end. Los begin y end son uno 
de los conceptos de estructuración del PASCAL. En programación, los con- 
ceptos favoritos vienen y pasan, pero el de la estructuración lleva ya varios 
años en la lista de los superventas. La razón de ello es fundamental: la única 
forma en que podemos esperar comprender un programa grande es construir- 
lo a base de subestructuras menores y más simples. 

Para hacernos una idea del objeto de begin y end, será instructivo conside- 
rar dos ejemplos de sentencias FOR en BASIC y en PASCAL: 


BASIC PASCAL 

10 FOR K = 1 TO 10 for k:= 1 to 10 do 
20 LETS =S+K s=s<+K 
30 NEXT K 
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60 FOR K =1 TO 10 for k:= 1 to 10 do 


70 LETS =S+K begin 

80 LETT=T+KxK s:=S + Kk; 

9 NEXT K ti= 1+ kxk; 
end; 


La sentencia FOR es la única construcción estructurada en el BASIC es- 
tándar mínimo. Cada FOR va acompañado forzosamente de un NEXT, y to- 
das las sentencias comprendidas entre ambos se tratan como una sola unidad. 
En el PASCAL hay muchas construcciones estructuradas dentro de los pro- 
gramas, y for es una de ellas. Varias de estas construcciones utilizan las pala- 
bras begin (principio) y end (final) para encerrar a un grupo de sentencias que 
se ha de tratar como una sola unidad. A esta unidad se la conoce con el nom- 
bre de sentencia compuesta. La construcción for en PASCAL no constituye 
por sí sola una sentencia. Es una cláusula que ha de ir como prefijo de una 
sola sentencia. Si queremos que for afecte a varias sentencias, ponemos begin 
y end encerrándolas; esto las convierte en una sentencia compuesta, que cuen- 
ta como una sola sentencia. En el primero de nuestros ejemplos for preceden- 
tes, no necesitamos begin ni end, porque es sólo una sentencia la que se ha 
de iterar. Sin embargo, no importa si se ponen begin y end de sobra o redun- 
dantes, de manera que podríamos haberlos puesto. En nuestro segundo ejem- 
plo, el begin y el end son necesarios, puesto que se ha de repetir más de una 
sentencia. 

Todo el cuerpo de un programa PASCAL entero va encerrado por un be- 
gin y un end. El end final se escribe 


end. 


El punto significa que éste es el final mismo del programa. Al igual que 
ocurre con FOR y NEXT, begin y end se anidan en forma natural, por ejemplo: 


begin (x* A x) 
(xk ... +) 
begin (x* B x) 
(* ... *) 
end; (x B x) 
(k ... *) 
begin (x* C x) 
(x* ... *) 
end; (x* C x) 
(* ... *) 
end; (x A x) 


Aquí, el begin que hemos marcado con la observación o el comentario 
(+* A x*) casa o se empareja con el end marcado similarmente, y así sucesiva- 
mente. Un buen programa se presenta gráficamente en tal forma que sea evi- 


dente a la vista cuáles son los begin y end que van emparejados o casados, 
por ejemplo: 


Desde luego, es un error que existan begin sin sus end correspondientes, 
y viceversa. 

Te darás cuenta de que, dada la preponderancia que en el PASCAL tienen 
los conceptos de estructuración, el tener un poco de cuidado en la disposición 
o presentación gráfica del programa producirá grandes dividendos en legibili- 
dad del mismo. Si tienes suerte, tu ordenador tendrá un programa o rutina 
de utilidad para lo que se conoce como prettyprinting (escritura bonita). Se 
trata de un programa que toma otro programa PASCAL y le da una disposi- 
ción limpia y decente. (También en BASIC existen programas de este tipo, pe- 
ro su tarea es menor y menos importante.) Sin embargo, aunque tales progra- 
mas son útiles para lo que pudiera llamarse un “aseo final””, es mucho mejor 
que te habitúes a dar a tus programas una disposición correcta ya desde el prin- 
cipio. 


Sentencias individuales 


Las sentencias individuales contenidas en nuestro programa de la mediaarit- 
mética son similares en los dos lenguajes BASIC y PASCAL, por ejemplo: 


BASIC PASCAL 

INPUT N read(n); 

LETS =S+X S=S+X; 

PRINT “MEDIA =””; S/N writeln(*Media=", s/n), 


En PASCAL, desafortunadamente desde el punto de vista del programa- 
dor de BASIC, se emplea read en la acepción de INPUT. En el PASCAL no 
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hay ningún concepto similar al de READ en BASIC, de manera que si, por 
error, empleas read para tratar de READ, pronto averiguarás que estás inten- 
tando lo imposible. 

La sentencia de asignación del PASCAL no lleva la palabra LET, pero son 
muchos los BASIC que también permiten omitirla. Más dificultoso o, por lo 
menos, molesto, resulta el **: =”” que hay que escribir en PASCAL en lugar 
del **=”” del BASIC. (Esto afecta igualmente a las sentencias for, como puede 
verse echando un vistazo a los ejemplos precedentes.) 

Las sentencias simples de salida del BASIC y el PASCAL son fundamen- 
talmente similares. La palabra writeln es una abreviatura más bien desafortu- 
nada de lo que se podría haber llamado, pero no se llamó, writeline. 

Finalmente, sin duda habrás observado que cada sentencia PASCAL lleva 
al final un punto y coma. En el BASIC, las sentencias se corresponden con 
las líneas del programa. En el PASCAL, el final de una línea se trata simple- 
mente como un espacio, de manera que hace falta una marca explícita que in- 
dique el final de una sentencia. Si dispusiéramos de un terminal con una línea 
fantásticamente ancha, podríamos escribir todo un programa PASCAL com- 
pleto en una sola línea. 

A título de ejemplo más prosaico, las siguientes líneas de PASCAL 


X:= 
3; 


Xx: 


1 
De 
Dd 
1 
+ 


tienen significados idénticos. 

No obstante, normalmente es mejor no aprovechar la ventaja de la flexibi- 
lidad que el lenguaje ofrece. Hasta que te acostumbres al PASCAL y desarro- 
lles un estilo propio en la disposición, lo más prudente es poner una sola sen- 
tencia en cada línea. 

Para hablar con exactitud, el punto y coma más bien sirve para separar 
las sentencias que para terminarlas. Ello significa que no hace falta el punto 
y coma después de la última sentencia de un grupo, es decir, después de la sen- 
tencia que precede a un end. Si, a pesar de todo, ponemos punto y coma antes 
de end, como lo hemos hecho en todos los ejemplos hasta ahora, lo que hace- 
mos en realidad es escribir una sentencia nula antes del end. Las sentencias 
nulas no producen acción alguna ni ocasionan ningún perjuicio. Si se te pega 
el dedo en la tecla del punto y coma y escribes 


x=3555 


habrás escrito tres sentencias nulas, pero ello no afectará a tu programa. Al 
PASCAL, como a la mayoría de nosotros, no le importa no hacer nada. 


Seguiremos ateniéndonos a nuestra convención de escribir punto y coma 
después de todas las sentencias (excepto después del último end, que lleva de- 
trás un punto). La única excepción, como veremos, es que nunca ha de haber 
un punto y coma precediendo a un else. Sin duda, nuestro convenio molestará 
a los puristas del PASCAL, pero tiene el mérito de hacer más fácil la edición 
de los programas. Por ejemplo, es posible insertar una sentencia nueva antes 
de un end sin necesidad de añadir un punto y coma a la sentencia que anterior- 
mente precedía al end. 


Números de línea 


El último punto es que los programas PASCAL no contienen números de 
línea. En el BASIC, estos números se usan para los GOTO y para editar. En 
el PASCAL, pocas veces se emplea el GOTO. Lo que importa más, y es una 
gran sorpresa para alguien que se haya formado en BASIC, el PASCAL no 
contiene ningún editor. Además, no lleva incorporados comandos u órdenes 
como RUN, SAVE, GET, OLD o NEW. En su lugar, todas estas posibilida- 
des nos las da un entorno exterior llamado un sistema operativo. Los sistemas 
operativos son como los gobiernos. Nominalmente, existen para nuestro bene- 
ficio; pero, en la práctica, son grandes y poco ágiles, es difícil comunicarse 
con ellos y, en general, son un estorbo aparente para nuestro programa. Ya 
hablaremos de esto en el capítulo 3. 

El PASCAL no es interactivo. En el BASIC, escribimos las líneas una a 
una en el compilador (cuando empleamos la palabra ““compilador”” en este li- 
bro, lo hacemos para designar lo mismo un compilador que un intérprete). En 
PASCAL, preparamos el programa completo usando un editor separado —es- 
to se explicará más adelante, por si acaso no has encontrado la idea 
anteriormente— y luego se lo aplicamos a un compilador. Hay por ahí uno 
o dos compiladores PASCAL interactivos o semi-interactivos, pero hasta aho- 
ra no han tenido mucha difusión. 


Sumario 


Hasta ahora hemos encontrado tres conceptos en los que se pone mucho 
más énfasis en PASCAL que en BASIC. Son los siguientes: 


e declaraciones, 
e tipos de datos, 
e estructuración. 
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Hemos hallado también que el PASCAL carece de las excelentes caracte- 
rísticas que posee el BASIC para la edición, la grabación (SAVE), la carga 
(LOAD) y, en general, el manejo de los programas. 


Algunos amigos 


En este momento, hemos de presentarte a dos de nuestros amigos. Bill Mudd 
lleva veinte años programando en BASIC. Uno de sus programas tiene 10.000 
líneas de BASIC, y funciona... por lo menos casi todas las veces. Sus comen- 
tarios sobre el material que hemos presentado hasta ahora en este libro no han 
sido muy estimulantes. 


““A mí el PASCAL me parece un lenguaje para académicos con la 
cabeza perdida entre las nubes, que nunca han escrito un programa real 
en toda su vida””, nos dijo. “Observe que el programa PASCAL dado 
como ejemplo es dos veces más largo que el correspondiente en BASIC. 
En especial, me divierten todas las cosas inútiles que hay que escribir. 
Hay que decir program al principio, por si acaso el ordenador piensa 
que lo que estás preparando es una lista para la compra. Luego hay que 
escribir otras varias líneas de morralla. Cuando finalmente se llega a la 
fase de la escritura del programa propiamente dicho, escribís begin, sólo 
para avisar al compilador que no habéis cambiado de idea, ni decidido 
dejar sin escribir el programa después de todo. Luego escribís práctica- 
mente lo mismo que en BASIC, salvo que, como eso sería demasiado 
fácil, tenéis que añadir un montón de puntos y coma, dos puntos, pa- 
réntesis y cosas.”” 


Bastante alterados por esta inculta y grosera actitud de Bill, consultamos 
a nuestro otro amigo, el profesor Primple. El profesor es un fanático del PAS- 
CAL. Al igual que Bill, lleva veinte años escribiendo programas. Ha escrito 
soluciones para el problema de las ocho reinas en treinta lenguajes de progra- 
mación diferentes, ha escrito funciones factoriales repetitivas en cuarenta y tres 
y, lo que es mejor, ha codificado la función de Ackermann en setenta y dos 
lenguajes. 


“*La conversión de los paganos siempre vale la pena, supongo””, nos 
dijo mientras se rascaba su barbita en gesto característico. “Tendrá que 
trabajar mucho para convertir a los salvajes de Basiclandia a los moda- 
les realmente buenos del PASCAL. Es una pena que haya empezado por 
simplificar excesivamente muchos de los conceptos y que, peor todavía, 
haya animado a los salvajes a ensuciar la belleza del PASCAL con pun- 
tos y coma innecesarios y redundantes.”” 


No existe eso que llaman una traducción literal. 


Un profesor de francés 


Los objetivos 
del PASCAL 


Ahora que hemos dado una idea de cómo son los programas PASCAL, 
vamos a estudiar en este capitulo los objetivos de este lenguaje y algunas de 
sus ventajas potenciales. 


Historia 


Uno de los hitos de la historia de la informática fue el desarrollo del len- 
guaje ALGOL 60. Los que, en nuestra época escolar, nos vimos torturados 
por unos profesores de historia que nos obligaban a recordar numerosas fe- 
chas, vemos con gusto el nombre del lenguaje ALGOL 60, puesto que el mis- 
mo nombre indica su fecha, 1960. El ALGOL 60 fue ideado y desarrollado 
por un comité de trece personas; pero, sorprendentemente, resultó una obra 
brillante que, desde entonces, ha influido siempre en el diseño de los lenguajes 
de programación. El ALGOL 60 propiamente dicho no ha conocido un uso 
muy extendido, tal vez porque se había adelantado a su tiempo, o quizá por- 
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que no había disponibles buenos compiladores en número suficiente; pero sus 
sucesores han conquistado el mundo. El ALGOL 60 contiene numerosas ideas 
buenas, pero una de las más importantes es la estructura en bloques. Más ade- 
lante estudiaremos este concepto. La idea es tan importante que, a causa de 
ella, el ALGOL 60 y sus sucesores han venido a ser conocidos como lenguajes 
estructurados en bloques. 

El lenguaje PASCAL fue desarrollado a finales de la década de los sesenta 
por el profesor Nicklaus Wirth, de la Eidgenóssische Technische Hochschule 
de Zurich. Es un lenguaje estructurado en bloques que continúa el camino ini- 
ciado por el ALGOL 60, introduciendo conceptos nuevos y simplificando otros 
ya existentes. Para 1973, el PASCAL había alcanzado ya su forma definitiva, 
y desde entonces ha conseguido un envidiable éxito. Al parecer, el profesor 
Wirth tenía en su pared un mapa del mundo en el que iba clavando alfileres 
sobre aquellos puntos en los que se utilizaba el PASCAL. Hoy, el mapa ha 
de estar tan perforado que seguramente habrá caído ya en pedazos. Además, 
este éxito del PASCAL no se debe a ninguna fuerte presión de ventas, ni al 
impulso de alguna organización poderosa. La gente ha elegido el PASCAL sim- 
plemente porque lo quería. 

Sin embargo, el PASCAL no ha monopolizado el campo de los lenguajes 
estructurados en bloques. Entre otros lenguajes ampliamente utilizados figu- 
ran el C, el BCPL, el ADA y el PL/I. Una vez aprendido el PASCAL, halla- 
rás que es relativamente fácil pasar a cualquier otro lenguaje estructurado en 
bloques, y viceversa. 


Características específicas de diseño 


Al llegar a este punto, vale la pena destacar dos características específicas 
de diseño del PASCAL que, dado que no las tienen sus competidores, han con- 
tribuido al éxito de este lenguaje. La primera es que el Pascal ha sido diseñado 
teniendo presentes los problemas de la realización o implementación. El resul- 
tado de ello es que los compiladores PASCAL funcionan en forma relativa- 
mente rápida, y producen un programa que también se ejecuta con rapidez. 
Además, los compiladores PASCAL no son tan gigantescos e incómodos co- 
mo los de otros lenguajes estructurados en bloques, lo cual explica el gran uso 
que se hace del PASCAL en microordenadores. 

La segunda de estas dos importantes características de diseño del PASCAL 
es que este lenguaje trata de ser breve y flexible. Una de las cualidades más 
grandes del diseñador de este lenguaje es que ha suprimido sin piedad todo 
rasgo potencial que no valiera la pena conservar. La recompensa obtenida ha 
sido un lenguaje fácil de aprender y de compilar. Sin embargo, no conviene 
ser despiadado a menos que las características principales del lenguaje tengan 


la flexibilidad suficiente, que permita plegarlas y adaptarlas para llenar los hue- 
cos que deje la poda. 

Se puede mantener (y nosotros mismos lo haremos) que algunas veces se 
han eliminado del PASCAL rasgos o características que no lo merecían, pero 
es difícil cuestionar el objetivo consistente en hacer un lenguaje pequeño o re- 
ducido. 


Definición del PASCAL 


En 1975, Springer-Verlag publicó el Informe y Manual del Usuario de PAS- 
CAL. Sus autores eran Kathleen Jensen y el propio Wirth. El ““informe”” es 
una definición bastante más formal del material presentado en el manual del 
usuario. 

A lo largo de este libro, nos referiremos muchas veces al informe del PAS- 
CAL, será de gran valor para ti el hacerte con un ejemplar del libro de Jensen 
y Wirth; también constituirá un eficaz complemento del tratamiento un tanto 
informal que de dicho lenguaje se hace en este libro. Si eres una persona refi- 
nada, deberás buscar una de las primeras ediciones de Jensen y Wirth, con su 
bonita cubierta marrón y gris. Si tu personalidad se inclina más a un estilo de 
vida moderno y brillante, preferirás sin duda la edición que tiene las tapas pla- 
teadas y con salpicaduras escarlata. 

El informe PASCAL sirvió como definición del lenguaje hasta que, en 1981, 
se produjo una norma internacional al respecto. La definición normalizada di- 
fiere muy poco del informe PASCAL, y en aquellos puntos en que hay dife- 
rencias, la mayoría de los compiladores actuales siguen a éste. En este libro 
nos referiremos alguna vez a la norma PASCAL, en aquellas situaciones en 
que ésta difiere del informe. 


Las variaciones en el BASIC y en el PASCAL 


Existen muchas realizaciones o implementaciones distintas del BASIC, que 
varían considerablemente entre sí en cuanto a los rasgos o características que 
ofrece cada una. Afortunadamente, sin embargo, la mayor parte de las versio- 
nes de BASIC poseen un núcleo central común, que es el que sirve de base 
para las explicaciones que damos en este libro. En realidad existe una norma 
ANSI para el BASIC mínimo, que en la actualidad va siendo cada vez más 
observada. (Se está realizando trabajo de normalización en algunos BASIC más 
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avanzados, pero, en el momento en que esto se escribe, su efecto en el ámbito 
de los usuarios ha sido muy escaso.) 

También hay, desde luego, muchas versiones o realizaciones distintas del 
PASCAL, pero todas tienden a ser bastante similares, puesto que todas están 
basadas en el informe del PASCAL. Para cualquier compilador PASCAL que 
pienses utilizar, deberás consultar el correspondiente manual del usuario, al 
que denominaremos tu manual local. En tu manual local debe haber una sec- 
ción que defina aquellos puntos en que tu compilador se aparte del informe 
o de la norma. Generalmente, hallarás una o dos ampliaciones y tal vez algu- 
nas restricciones esotéricas, pero nada de gran importancia. Como ya hemos 
dicho anteriormente, este libro no se ocupa de las ampliaciones no oficiales 
del PASCAL, por muy populares que puedan ser, de modo que para la des- 
cripción de ellas habrás de depender exclusivamente de tu manual local. 

Cuando digamos en este libro que tal característica o rasgo “no existe en 
el PASCAL” o “no existe en el BASIC”, nos referimos a las versiones están- 
dar definitivas. Indudablemente, tú podrás descubrir versiones o realizaciones 
individuales de PASCAL o de BASIC que incluyan efectivamente tales carac- 
terísticas “ausentes”. 


Portabilidad 


Si tu programa ha de lograr éxito y larga vida, ha de ser portátil. Esto quie- 
re decir que el programa ha de poder moverse fácilmente de una máquina a 
otra, o entre dos compiladores diferentes en la misma máquina. Si evitas las 
ampliaciones no oficiales de los compiladores, hallarás que los programas PAS- 
CAL son bastante portátiles. Nadie que haya trasladado un programa grande 
de un ordenador a otro lo ha conseguido sin experimentar algunas dificultades 
o tropezar con algún problema. Sin embargo, tus problemas serán menos con 
el PASCAL que con la mayoría de los lenguajes. 

En este aspecto, el BASIC es mucho peor que el PASCAL. Entre los dis- 
tintos sistemas BASIC hay enormes variaciones, y habrá dificultades igualmente 
grandes cuando se trate de trasladar un programa BASIC largo de un sistema 
a otro. Tu única esperanza es limitarte al BASIC de un vendedor determina- 
do, o atenerte exclusivamente al BASIC mínimo de la norma ANSI. 


Método de ejecución 


Si posees algunos conocimientos sobre software de sistemas, comprende- 
rás que existe una diferencia entre un intérprete y un compilador. Si luego apren- 


des mucho más sobre software de sistemas, hallarás que los dos conceptos no 
son tan diferentes como tú pensabas. En este libro no nos ocupamos de puntos 
tan sutiles. Por eso es por lo que describimos cualquier sistema BASIC o PAS- 
CAL como un ““compilador””, evitando así la constante repetición de ““intér- 
prete o compilador”. 

El tratamiento de un programa en el ordenador se hace en dos etapas o 
fases. Primero, el compilador convierte nuestro programa a una forma inter- 
na y, si existen errores de sintaxis, se nos advierten. Segundo, si la compila- 
ción se ha completado con éxito, se ejecuta (run) la forma interna del progra- 
ma. Estas dos fases o etapas se denominan “tiempo de compilación”” (compile- 
time) y “tiempo de ejecución” (run-time). (El programa del sistema que ma- 
neja nuestro programa durante la ejecución se llama el ““sistema de ejecución”, 
o run-time system.) Estas dos fases o etapas son completamente distintas 
en el PASCAL, aunque en algunos BASICs, especialmente los muy pequeños 
que no dan los errores de sintaxis hasta que se ejecuta el programa, la diferen- 
cia es menos evidente. 


Algunas consideraciones prácticas 


En un ordenador pequeño, tu elección de lenguaje puede estar determina- 
da más por serias limitaciones prácticas que por puntos estéticos de orden más 
elevado. En tales términos prácticos, la comparación entre el PASCAL y el 
BASIC viene a dar los siguientes resultados: 


1) Tamaño de la memoria. Un compilador PASCAL necesita mucha más me- 
moria que uno de BASIC. A medida que pase el tiempo y la memoria de 
los ordenadores se vaya haciendo más barata, esta consideración irá per- 
diendo importancia. 


2) Velocidad de compilación. La compilación en el PASCAL es más rápida 
que en la mayoría de los lenguajes estructurados en bloques, pero todavía 


tiende a ser más lenta que en los lenguajes estructuralmente más simples, 
como el BASIC. 


3) Velocidad de ejecución. Inherentemente, la ejecución de los programas 
PASCAL no es ni más lenta ni más rápida que la de los de BASIC. Las 
diferencias que puedan hallarse procederán de la calidad de las versiones 
individuales. 


Resumiendo, si tu única preocupación en la vida es el aprovechamiento avaro 
de la capacidad de memoria y del tiempo de máquina, es poco probable que 
el cambio desde el BASIC al PASCAL represente una ayuda para ti. 
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Puntos o cuestiones relativos a los lenguajes 


Supongamos, sin embargo, que tus horizontes son más amplios que el de 
la avaricia extremada. Vamos a dedicar el resto de este capítulo a puntos algo 
más elevados y, en particular, a considerar las ventajas potenciales que el PAS- 
CAL tiene sobre el BASIC como lenguaje de programación. 

El BASIC posee tres grandes ventajas. Es fácil de aprender, es fácil de usar 
y es bueno para la escritura de programas pequeños. 

Cuando uno lleva algún tiempo programando, descubre que los programas 
grandes son fundamentalmente diferentes de los pequeños. Al hablar de ““gran- 
des””, nos referimos a varios cientos de líneas. (Para un programador profe- 
sional, un programa ““grande”” podría ser de miles o incluso millones de líneas, 
pero nosotros seremos más modestos.) Cuando un programa se hace grande, 
hay una consideración que predomina sobre todas las demás: el programa ha 
de ser fácil de leer y de entender, tanto para su autor como para los demás. 
Si se consigue esto, casi todas las demás propiedades favorables se dan por 
añadidura. El programa se hace fácil de desarrollar, tanto inicialmente como 
cuando se hagan adiciones posteriores. El programa se hace fácil de depurar 
y de corregir. Se hace fácil de compartir: un grupo de personas puede colabo- 
rar en un programa, o tú puedes escribir un programa original tuyo y dejar 
que otros lo mejoren o amplíen, trabajando a partir de él. También se hace 
más fácil el trabajo de hacer que el programa funcione bien y en forma fiable, 
y el tener confianza en él. Finalmente, hay un argumento realmente invencible 
en favor de la legibilidad: si tu programa no es legible, nadie podrá darse cuenta 
de lo estupenda que es tu programación. 

Si escribes un programa pequeño que no sea fácil de entender, ello no im- 
porta mucho. Todavía será posible seguirlo para ver qué es lo que trata de ha- 
cer. Si llevas las mismas costumbres de programación a un programa grande, 
naufragarás por completo, porque tu programa se hará imposible de entender 
para una mente humana ordinaria. Los programas de PASCAL son, inheren- 
temente, más legibles que los de BASIC, y ésta es la primera razón que habrás 
de considerar al hacer el cambio. Tal vez en este momento no estés de acuerdo 
con esta aserción, pero lo estarás con toda seguridad cuando tengas una com- 
prensión adecuada del PASCAL. Sólo como prueba, trata de hacerte con algu- 
nos programas en PASCAL (por ejemplo, de alguna revista o de alguna bi- 
blioteca) en un campo que te interese, y cuando tengas ya algo de idea del PAS- 
CAL como lenguaje, verás hasta qué punto son legibles los programas. 


Mantenimiento 


El argumento relativo a la legibilidad se puede reforzar si se considera lo 
que ocurre con un programa satisfactorio a partir del momento en que se ha 
escrito. 


Probablemente no exista ningún programa que se haya utilizado durante 
años sin ninguna modificación. Por el contrario, todos los programas necesi- 
tan lo que se conoce como mantenimiento. En el mantenimiento entran la de- 
puración o corrección de defectos y la introducción de pequeños cambios o adi- 
ciones. Tales cambios serán consecuencia de peticiones del usuario, o de cam- 
bios en el hardware o en el software con los que se ejecute el programa. Para 
un programa típico de producción, los costes de mantenimiento son muchas 
veces mayores que los de la escritura inicial del programa. Así, pues, el objeti- 
vo de un lenguaje de programación debe ser crear un programa que sea fácil 
de mantener; y, si es necesario, habrá de hacerse aun a costa de hacer más difí- 
cil su escritura inicial. 

Si tú trabajas en un entorno de producción, tal vez haya un punto claro 
y definido en el que comienza la etapa de mantenimiento. Tú escribes tu pro- 
grama y lo sometes a un proceso al que (risiblemente) se denomina **“compro- 
bación final”. Cuando el programa ha superado esta prueba, pasa a otros pa- 
ra su utilización. 

Al cabo de un tiempo muy corto, los usuarios vuelven con denuncias de 
errores o con peticiones de cambios, y, a partir de ese momento, empiezas a 
gustar las mieles y las delicias del mantenimiento. 

Si, en cambio, escribes programas sólo para tu propio uso y tal vez para 
el de algunos amigos y colegas, la transición de la fase de desarrollo a la de 
mantenimiento es más gradual. Escribe una versión inicial, la usas un poco 
y luego decide en qué puntos deben hacerse modificaciones o desarrollos adi- 
cionales. Entonces produce una Versión 2. Llegará un momento en que te da- 
rás cuenta de que estás dedicando la mayor parte de tu tiempo a introducir 
cambios y pequeñas modificaciones, en lugar de a la escritura de rutinas com- 
pletamente nuevas. Entonces habrás entrado en la fase de mantenimiento. 

El mantenimiento puede ser realizado por la misma persona que escribió 
el programa, o bien por alguien distinto. En realidad, no hay mucha diferen- 
cia entre los dos casos. Todos hemos experimentado el fenómeno de mirar a 
uno de nuestros propios programas, escrito un año antes o cosa así, y pensar: 
“¿Quién será el idiota que escribió este programa? No entendiendo en absolu- 
to qué es lo que trata de hacer.”” Es exactamente igual que si el programa lo 
hubiera escrito otro. 

Incluso si pones en duda nuestra aseveración de que la legibilidad hace más 
fácil el desarrollo inicial de los programas, ya de entrada (y, desde luego, hay 
derecho a sospechar de la labia que derrochan en sus afirmaciones muchos li- 
bros), sin duda convendrás en que todas las ventajas de la legibilidad se ponen 
de manifiesto durante el mantenimiento de los programas. 


Niveles de legibilidad 


Existen varias formas diferentes de conseguir la legibilidad. Algunas de las 
importantes son las siguientes: 
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1) Hacer que cada sentencia sea fácil de leer. 

2) Estructurar el programa. 

3) Hacer que el programa esté estrechamente relacionado con el problema. 
4) Imponer una disciplina en el estilo de programación. 

5) Separar aquellos elementos del programa que puedan necesitar cambios. 


Trataremos sucesivamente cada una de ellas, relacionándolas con las faci- 
lidades del PASCAL. 


Hacer que las sentencias sean fáciles de leer 


La ayuda más grande en que se puede pensar para hacer que las sentencias 
individuales sean comprensibles, es usar para las variables, subrutinas, etc., 
nombres que tengan el mayor significado posible. Consideremos las tres sen- 
tencias equivalentes que siguen en tres lenguajes, el BASIC, el PASCAL y el 
COBOL: 


LET P3 = Pl + P2 

pagatotal:= pagafija + pagahorasextra; 

ADD OVERTIME__PAY TO FIXED__PAY GIVING TOTAL__PAY. 
(Súmese la paga por horas extra a la paga fija, dando paga total.) 


Evidentemente, la versión en BASIC es la más difícil de comprender. La 
versión en COBOL es interesante en cuanto que utiliza una sintaxis análoga 
a la inglesa. El lenguaje COBOL es muy utilizado por los programadores co- 
merciales, y muy despreciado (un tanto injustamente) por todos los demás. Los 
programas son tan verborreicos que el equivalente del programa BASIC 


PRINT 2 + 2 


ocuparía alrededor de veinte líneas de COBOL. Una de las ideas originales en 
que se basó el COBOL era que los programas habrían de ser comprensibles 
para contables, gerentes, etc., que no saben absolutamente nada de progra- 
mación. 

Al hablar del COBOL nos hemos desviado para sugerir algunas ideas so- 
bre la sintaxis de los programas. ¿Sirve de ayuda la notación en un lenguaje 
similar al inglés? Puede argumentarse que no sirve de ayuda en el manteni- 
miento de programas, porque es presumible que el encargado de este trabajo 
esté ya habituado a la notación de su lenguaje de programación. Lo que sí que 
ayuda, con toda seguridad, es el dar a los objetos manipulados unos nombres 
que indiquen su finalidad. 


Estructuración 


No es posible estar mucho tiempo en informática sin que le lancen a uno 
a la cara el concepto de “estructuración”. Los vendedores de toda clase de 
productos de software proclaman que éstos son estructurados, y casi todos los 
artículos de software mencionan “programación estructurada””. Sólo el pro- 
fesor Primple ha escrito 158 comunicaciones sobre este tema; pero, desgra- 
ciadamente, no disponemos de espacio para reproducirlas aquí. 

Indudablemente, toda la presión de ventas aplicada a la estructuración ha 
hecho que mucha gente reaccione negativamente ante este tema. Sin embargo, 
esa reacción no está justificada realmente. La estructuración es una chica bue- 
na de la programación. Le daremos el nombre de Sra. Buzz, por la abeja reina 
que, al imponer una estructura celular, consigue dirigir a miles de obreras pa- 
ra que construyan un conjunto coherente. La única forma en que podemos 
construir programas realmente grandes, y no digamos mantenerlos, es dividir- 
los en partes más sencillas, que puedan unirse entre sí para constituir el progra- 
ma entero. Hay muchos métodos diferentes que caben bajo el encabezamiento 
de “programación estructurada””. La elección entre las distintas alternativas 
tal vez no sea demasiado crucial, pero lo que sí es vital es que sigamos la direc- 
triz de la Sra. Buzz al tener alguna filosofía general, que sea práctica y cohe- 
rente, para estructurar lo que hagamos. Sea cual sea la filosofía que escoja- 
mos, el PASCAL nos proporcionará herramientas que nos ayuden, aunque, 
indudablemente, no todo lo que querríamos. 

Desde luego, hay muchos programas cuya escritura es obra de un equipo, 
y no de una sola persona. En estos casos, un lenguaje de programación no só- 
lo ha de ayudar a distribuir el programa en subprogramas, sino que también 
ha de facilitar el que diferentes personas trabajen en los subprogramas sin in- 
terferirse. El PASCAL tiene un concepto de ámbito local, mediante el cual las 
variables pueden pertenecer a un subprograma y ser invisibles para otros. 


Relación con el problema 


Si programamos en BASIC, hemos de representar todo el mundo mediante 
variables que son del tipo de datos numérico o del de cadena (string). Sin em- 
bargo, hay muchos problemas del mundo real que no encajan naturalmente 
en tales tipos de datos. Si el programa simula el funcionamiento de un semáfo- 
ro de tráfico, por ejemplo, el tipo de datos naturalmente asociado con él con- 
siste en el juego de valores rojo, ámbar y verde (más rojo y ámbar juntos, en 
algunos países). Si representamos estos valores como 1, 2 y 3, nos perdemos 
algo. Esto es tan importante que nos lleva a presentar al primer malo de la 
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programación. Se trata del Sr. 869704, que nos estimula a pensar en números 
cuando los nombres serían mejor. Como veremos, el PASCAL tiene muchas 
formas de mantener a raya al Sr. 869704. 


Imponer una disciplina 


Uno de los placeres indiscutibles de la programación es la utilización inteli- 
gente de un lenguaje, o el empleo de trucos en él para hacer que el programa 
sea extracorto o extrarrápido. Aunque sea triste decirlo, estos placeres están 
más que contrarrestados por las agonías que producen cuando, durante la eta- 
pa de mantenimiento, hay necesidad de modificar un programa. 

El PASCAL intenta imponer disciplina a los programadores al hacer que 
los trucos sean difíciles o imposibles y, en algunos casos, imponiendo una for- 
ma estandarizada de hacer las cosas. Los programas disciplinados son fáciles 
de entender. 

Si has estado habituado a una mayor libertad, llegarás a considerar a tu 
compilador PASCAL como un maestro exigente y estricto. Ciertamente, uno 
tiene todavía la oportunidad de ser creativo, y hasta de divertirse, pero hay 
que seguir estrictamente las reglas del juego. 

La disciplina tiene una finalidad, aparte de la de hacer los programas legi- 
bles. Está orientada a hacer que los errores sean menos. La correción de erro- 
res es una parte importante de los costes de mantenimiento de un programa, 
de modo que las economías potenciales en este aspecto son enormes. Si segui- 
mos una disciplina de programación, nos será mucho más fácil comprobar si 
un programa hace lo que se pretende de él. Todavía sería mejor si hubiera mé- 
todos automáticos para verificar que los programas funcionan. El profesor 
Primple lleva muchos años trabajando en un sistema de este tipo. “Tengo un 
buen método, que funciona especialmente bien con el problema de las ocho 
reinas””, dice, *“pero, desgraciadamente, mis alumnos y mis colegas no tienen 
la inteligencia suficiente para comprenderlo.” 

Dado que tal vez no estemos capacitados para utilizar las herramientas de 
Primple, generalmente tenemos que hacer nuestra verificación mediante la la- 
boriosa comprobación manual. Pues bien, la disciplina de programación es un 
regalo de los dioses, sea cual sea el método de verificación que se emplee. 

Nos hemos encontrado a Bill Mudd sentado ante su terminal, y le hemos 
preguntado acerca de la programación ingeniosa e inteligente. “Me alegro de 
que me hayas preguntado eso,”” dijo con excitación. “Este programa de BA- 
SIC que tengo aquí lleva dos subrutinas que se solapan, la una desde la línea 
1300 a la 1721, y la otra desde la 1529 a la 1961. ¿Ves?, una salta sobre el 
RETURN de la otra. Lo verdaderamente ingenioso es que las dos están semi- 
anidadas en un bucle FOR que hace que... No, espera un momento. Ahora que 
lo pienso, hace que...”” 


Separación de las partes que puedan necesitar cambios 


Una faceta de un programa que muy bien puede necesitar la introducción 
de cambios la constituyen sus constantes. Aunque parezca paradójico, muchas 
veces las constantes no son constantes. Está claro que el valor de pi lleva mu- 
cho tiempo siendo 3,14159... e indudablemente continuará manteniendo su 
constancia. Similarmente, las probabilidades de que los catedráticos de Uni- 
versidad reciban una paga adecuada seguirán siendo cero. Sin embargo, los 
programas frecuentemente contienen constantes que representan cosas tales co- 
mo las dimensiones de una matriz o array, el ancho de una línea impresa, O 
el número máximo de registros que es posible procesar. Todas ellas es proba- 
ble que cambien cuando se haga mantenimiento en el programa, o cuando éste 
se ejecute en un entorno nuevo y distinto. 

El PASCAL tiene un medio para declarar las constantes, de modo que sea 
fácil cambiarlas más adelante. Esto tiene también la ventaja de que el signifi- 
cado de una constante arbitraria se vea claro también... a condición de que 
se dé a la constante un nombre sensato. 

El cambio de constantes es, desde luego, una pequeña parte de la tarea total 
que supone el mantenimiento de un programa. Sin embargo, el PASCAL ayu- 
da también a la Sra. Buzz al hacer que nos sea más fácil localizar los efectos 
de los cambios. Sin embargo, no seríamos leales si no te advirtiéramos que no 
puede uno pasarse en estos esfuerzos. Como principio general, si empleas una 
gran dosis de esfuerzo en la predicción de las partes de un programa que cam- 
biarán y las que no van a hacerlo, tendrás tanto éxito como los economistas 
que tratan de predecir las finanzas de la nación. 


Errores 


Para la mayor parte de la gente, el trabajo de programación está domina- 
do por una sola actividad: la depuración. Esto es aplicable tanto durante el 
mantenimiento como durante el desarrollo original del programa. El ocuparse 
de los errores o, mejor dicho, de la posibilidad de que existan o se produzcan 
errores, lo invade todo. Tanto la disciplina como la estructuración y la verifi- 
cación contribuyen a reducir los errores, pero no los eliminan. (Hay una ex- 
cepción cuando se trata de las actividades de programación del profesor Prim- 
ple. Aparte de su herramienta automática de depuración, ha postulado una 
nueva disciplina de la programación estructurada. Está tratada en diecisiete 
de sus artículos técnicos más recientes y, según se dice, elimina los errores, es- 
pecialmente en la función factorial.) 

Aunque la mayoría de nosotros nunca puede esperar eliminar los errores, 
podemos hacer esfuerzos realistas para reducir los efectos de los mismos. El 
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principio más importante es que, cuanto antes se encuentre un error, más fácil 
será arreglarlo. 

A continuación se da un espectro de los momentos en que pueden encon- 
trarse errores: 


1) antes de someter un programa al ordenador; 

2) por el compilador; 

3) inmediatamente que el error se manifieste durante una ejecución 
(run); 

4) durante una ejecución, pero después que el error real haya produci- 
do una serie de efectos secundarios consiguientes; 

5) al ver que las respuestas o soluciones son falsas; 

6) por algún desastre subsiguiente en el mundo real, como resultado 
de respuestas o soluciones incorrectas del ordenador: nuestro avión, 
con una capacidad de diez litros en vez de diez millones de litros en 
el depósito de combustible, se ve implicado en un grave accidente. 


La diferencia entre 3) y 4) se verá mejor por medio de un ejemplo. Si el 
error es un subíndice demasiado grande en una matriz o array, podrá ser detecta- 
do en el momento en que se emplee dicho subíndice. Sin embargo, algunos 
sistemas no detectan tal error, sino que en vez de ello dan al elemento de la 
matriz algún valor raro (gash value) y siguen a tontas y a locas. Entonces el 
error puede manifestarse algún tiempo después, cuando este valor extraño ha- 
ya corrompido a otras muchas variables y el programa termine, por ejemplo, 
sacando la raíz cuadrada de un número negativo. 

El objetivo de un lenguaje de programación, y el tuyo como programador, 
debe estribar en proveer una serie de redes de seguridad para cazar los errores 
tan pronto como sea posible. Será especialmente valioso si tu lenguaje de pro- 
gramación permite localizar en el momento de la compilación estos errores que 
potencialmente se pondrán de manifiesto al tiempo de la ejecución. El PAS- 
CAL facilita ayuda para esto. 

Se empleará la expresión general seguridad para designar las técnicas enca- 
minadas al descubrimiento temprano de los errores. El encargado de la seguri- 
dad es nuestro segundo bueno. Le llamaremos Perkins, como un hombre que 
conocemos y que es admirable. No esperes que Perkins evite todos los desas- 
tres; lo que sí consigue (y ya es algo de inmenso valor) es hacer que los desas- 
tres sean menos probables. 


Evaluación 


El examen precedente puede haber dejado la idea implícita de que, en las 
cinco facetas estudiadas, el PASCAL es lo más grande y el BASIC no vale pa- 
ra nada. Esta sería una opinión excesivamente simplista. 


Para empezar, la mayoría de los BASIC contienen ampliaciones que pro- 
veen muchas de las facilidades mencionadas. De hecho, el éxito del PASCAL 
ha dado lugar a que muchas características del mismo se hayan infiltrado en 
el BASIC. Actualmente, casi todas las versiones de BASIC contienen bastan- 
tes más cosas que el BASIC mínimo de la norma ANSI. Tales ampliaciones 
están bien, pero adolecen de un problema que podremos apreciar mejor por 
medio de un ejemplo. 

Uno puede empezar con una sencilla casa de un solo dormitorio y ampliar- 
la gradualmente hasta terminar teniendo una catedral. Sin embargo, no es pro- 
bable que el resultado final se parezca mucho a la catedral de Ely o a la de 
Chartres. De un modo análogo, las ampliaciones añadidas a los lenguajes de 
programación no llegan a formar un todo coherente y bien trabado; las proba- 
bilidades de éxito son mucho mayores si los objetivos de diseño se conocen 
desde el principio. (“Según mi guía””, dijo Bill, “la Catedral de Ely se comen- 
zÓ a construir en 1083, fue ampliada por diversos personajes sucesivamente 
hasta 1322, fecha en la que parte de ella se derrumbó, y luego fue reconstruida 
de una manera distinta.””) 

En el transcurso de las últimas décadas se ha aprendido una importante 
verdad (la han aprendido aquellos que querían aprender). Dicha verdad es que 
también en el mundo de los lenguajes de programación tiene razón el refrán 
que dice que “oficial de muchos oficios, maestro de ninguno””. Es mucho me- 
jor tener distintos lenguajes de programación (idealmente, breves y flexibles) 
para cubrir diferentes aplicaciones. (Si estos diferentes lenguajes tienen un nú- 
cleo común, tanto mejor). Al igual que sucede con los seres vivos en la natura- 
leza, cada lenguaje de programación tiene su propio nicho ecológico en el que 
prospera. El BASIC lo hace allí donde los programas son pequeños, la capaci- 
dad de memoria es limitada, y los usuarios no tienen pretensión alguna de ser 
programadores. El PASCAL prospera cuando los programas son más gran- 
des, las máquinas tienen mayores capacidades de memoria, y los usuarios, sin 
que sean necesariamente programadores de jornada completa, tengan prepa- 
ración suficiente para poder emplear tiempo y esfuerzo en la programación. 
Como veremos, el PASCAL tiene también sus puntos flacos, y está superado 
por otros lenguajes en muchos entornos. Con muchos esfuerzos y molestias, 
se puede llegar a cultivar uvas en el Artico, o a criar pingúinos en el desierto; 
del mismo modo, es posible mantener artificialmente un lenguaje de progra- 
mación en un entorno en el cual debería morir. 


Los seres humanos y la disciplina 


También es posible escribir buenos programas en BASIC y malos progra- 
mas en PASCAL. Todos conocemos a gente de la que se puede garantizar que 
escribirá programas malos, inmantenibles y llenos de errores, sea cual sea el 
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lenguaje de programación que utilice. A la inversa, un buen programador ge- 
nerará un producto razonable incluso si tiene que usar el BASIC. Se pueden 
escribir programas disciplinados en BASIC, aunque hay que autoimponerse 
la disciplina. El excelente libro The little book of BASIC style (El librito de 
estilo del BASIC, Nevison, 1978) provee una base para esta disciplina. 

Así pues, sólo se puede decir que el PASCAL ayuda a escribir programas 
disciplinados y fáciles de mantener, pero que los factores humanos tienen una 
importancia igual cuando menos a la de la selección del lenguaje de programa- 
ción. Un buen libro sobre estilo y disciplina en el PASCAL es el titulado PAS- 
CAL with style (PASCAL con estilo, Ledgard, Hueras 8 Nagin, 1979). 


El cambio en la forma de pensar 
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Llegamos ahora a la cuestión más importante que destacamos en este li- 
bro. No sirve absolutamente de nada escribir un programa en PASCAL si se 
va a seguir pensando en BASIC. En efecto, se pueden escribir programas en 
PASCAL que no son sino programas en BASIC con una sintaxis un poco dife- 
rente, pero eso no es en realidad usar el PASCAL. Lo que hay que hacer es 
cambiar la forma en que se piensa para resolver los problemas de la programa- 
ción. Los mecanismos que ofrece el PASCAL, de los cuales aún no hemos men- 
cionado la mayor parte, nos permiten enfocar los problemas y enfrentarnos 
a ellos en formas radicalmente nuevas. Por tanto, cuando hablamos de ““apren- 
der PASCAL””, nos estamos refiriendo a algo mucho más importante que al 
simple aprendizaje de las reglas gramaticales y semánticas de este lenguaje. 

Sabemos, desde luego, que no es fácil cambiar la forma de pensar. Como 
dijimos ya en el Prefacio, es más difícil aprender PASCAL sabiendo BASIC 
que sin saber programar absolutamente nada. El profesor Primple dice que 
el BASIC corrompe la mente. “Lo malo del BASIC es que no tiene ningún 
valor””, declara riéndose con sorna, mientras los que le oyen gimen por den- 
tro. (N. del T.: Hay en la frase anterior un juego de palabras intraducible en 
español, entre WIRTHLESS = “sin Wirth”, creador del PASCAL, y WORTH- 
LESS = ““sin valor o utilidad””; parece que es el juego de palabras precisa- 
mente lo que hace gemir a los oyentes.) 

Finalmente, recordemos la cita que figuraba al comienzo de este capítulo. 
Lo que decía el profesor de francés era que si una traducción se hace literal- 
mente, es decir, palabra por palabra y frase por frase, no será en realidad una 
traducción, pues no será correcta en absoluto. La traducción literal es nuestro 
segundo malo de la programación, con lo cual ya tenemos dos malos que se 
oponen a nuestros dos buenos. Este malo actúa insidiosamente sobre nuestros 
programas, llenándolos de tropiezos y cosas desagradables. Le llamaremos 
Frank Round (Redondo Franco), dándole el nombre producido por un progra- 
ma de traducción automática para interpretar la expresión “circuito abierto”. 


dd 
TY OC? A na 
REE ZADÓS SAS 


(POR 00 
Y O 


Utilizar el (aquí, el nombre de un conocido sistema operativo), es como intentar 
mover una ballena muerta a patadas a lo largo de una playa. 


S.C. JOHNSON 


Sistemas 
operativos 
y editores 


En el capítulo 1 dijimos que para usar el PASCAL necesitas entrar en un 
mundo que eludiste o rodeaste con el BASIC: el mundo de los sistemas opera- 
tivos y los editores. Cuando este libro se haga especialmente aburrido u oscu- 
ro, te resultará agradable tomarte un descanso en su lectura y escribir algunos 
programas propios en PASCAL. A fin de que puedas hacerlo, vamos a tratar 
ahora de los sistemas operativos y de los editores. Si ya tienes conocimientos 
de estas cosas —como puede ser el caso de la mayoría de los lectores—, puedes 
saltar este capítulo y así pasar más rápidamente a saborear los placeres que 
te esperan más adelante. 


Los microordenadores y los grandes ordenadores 


Lo más probable es que hayas empleado el BASIC en un microordenador. 

El PASCAL se inició como lenguaje en grandes y costosos ordenadores del 
tipo de unidad central, y sólo posteriormente llegó a estar disponible para los 
microordenadores. Todavía ahora, una importante proporción del uso del PAS- 
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CAL se hace en ordenadores grandes, aunque actualmente se va haciendo ca- 
da vez más difícil diferenciar entre uno de ellos y un microordenador. 

No obstante, todavía existen diferencias en la filosofía del software. Un 
gran ordenador central suele dedicarse a atender a una enorme gama de usua- 
rios distintos. Sus servicios y sus programas de utilidades están diseñados lo 
mismo para una compañía de seguros con veinte millones de pólizas que para 
usuarios individuales. El resultado es una inmensa mezcolanza que, como ve- 
remos, puede resultar difícil aprender. Un micro, en cambio, está desarrolla- 
do y equipado pensando mucho más en los pequeños usuarios individuales. 
El PASCAL puede ser similar en los dos tipos de máquinas, pero es más que 
probable que los medios y servicios y los programas de utilidades que le ro- 
deen sean totalmente distintos. 

Cuando uses el PASCAL por primera vez, puede que sea al mismo tiempo 
tu primera experiencia con el trabajo en grandes ordenadores centrales. Inclu- 
so si sigues usando el familiar microordenador, puede constituir una experien- 
cia nueva, ya que habrás de adaptarte a utilizarlo en una forma con la que 
no estás familiarizado. El punto clave en el uso del PASCAL es que los pro- 
gramas se preparan en una forma que es completamente diferente de la del 
BASIC, y comenzaremos el capítulo explicando esta dicotomía. 


Lenguajes interactivos y no interactivos 


El BASIC es un lenguaje interactivo. El PASCAL es un lenguaje no inte- 
ractivo. Al cambiar desde un lenguaje interactivo a uno que no lo es, tendrás 
la impresión de estar dando un paso atrás, porque la preparación y la compila- 
ción de los programas se convierten en un proceso mucho más aburrido y pro- 
lijo. Por tanto, si vas a enfrentarte a este cambio ha de ser con la confianza 
de que el PASCAL es un lenguaje mucho mejor que el BASIC. Una vez que 
se ha avanzado hasta el punto de ejecutar el programa, ya no existe mucha 
diferencia: puedes interaccionar con tu programa exactamente igual que con 
uno en BASIC. 

La mejor forma de explicar la diferencia entre un lenguaje interactivo y 
otro que no lo es, es empezando con una analogía. Un lenguaje interactivo es co- 
mo un supermercado, en donde hay toda clase de artículos o mercancías reu- 
nidos bajo un solo techo. No sólo puedes adquirir toda clase de productos u 
objetos, sino que puedes deambular al azar desde una sección del supermerca- 
do a otra y, suponiendo que no hayas pasado por la caja, puedes cambiar de 
idea en cuanto a las compras que ya hayas hecho. Por ejemplo, puedes estar 
en la sección de vinos y darte cuenta de repente de que no has elegido bien 
en la sección de frutas cuando cogiste la variedad de manzanas inadecuada- 
mente denominada *“Golden””; en tal caso, puedes volver a Frutas y Verduras 


y enmendar el error tomando, por ejemplo, manzanas «reineta». Del mismo 
modo, si decides que no te puedes pasar sin comprar una barra de chocolate 
almendrado, aun cuando antes, con gran espiritu de renuncia, hayas pasado 
junto a ellas, sin tocarlas, puedes volver atrás y meterlas en tu cesta. 

En el BASIC puedes preparar programas, listarlos, grabarlos, ejecutarlos, 
recuperar programas antiguos, etc. Todo ello se hace por medio de un conjun- 
to de órdenes o comandos contenidos en el BASIC, tales como LIST, RUN, 
SAVE, etc. El uso de estas órdenes equivale a pasar a las distintas secciones 
del supermercado del BASIC. Además, en BASIC es fácil editar (es decir, mo- 
dificar el programa, insertando nuevas líneas entre las existentes o sustituyen- 
do algunas de éstas... exactamente igual que al cambiar las manzanas). 

Un buen BASIC, en un ordenador con una capacidad de almacenamiento 
razonable, va en realidad más allá de nuestra analogía. Si has escrito inadver- 
tidamente una sentencia incorrecta, tal como 


LETA =B + /C, 


se te avisa inmediatamente de tu error; no tendrás el problema de darte cuen- 
ta, después de salir del supermercado, de que has escogido mal los géneros com- 
prados. 

El empleo del lenguaje no interactivo se parece más a un grupo de pequeños 
comercios especializados, esparcidos por toda la ciudad. Uno es exclusivamente 
panadería y pastelería, otro carnicería y charcutería, otro frutería y verdule- 
ría, etc. Entras en la charcutería a comprar jamón para bocadillos. El jamón 
de la charcutería lo cortan para ti de junto al hueso y tiene un gusto estupen- 
do, en contraste con el del supermercado, que se diferencia poco del plástico 
con el que lo envuelven. Sin embargo, si, al comprar el jamón, te das cuenta 
de que no compraste pan cuando estabas en la panadería, tendrás la molestia 
de tener que recorrer todo el camino de vuelta a ella para enmendar tu error. 
Además, suponiendo que te guste poner mantequilla en los bocadillos, tal vez 
tengas que volver también a la mantequería a comprarla. 

El uso del PASCAL se parece a un recorrido por una serie de tiendas dife- 
rentes. Empezamos por la tienda en la que se escriben y se editan programas. 
Luego se pasa a la tienda del compilador para comprobar el programa y pre- 
pararlo para su ejecución. Si el programa está mal, hay que volver a la tienda 
de la edición; en caso contrario, se sigue a la tienda para la ejecución de pro- 
gramas. Si la ejecución produce resultados incorrectos, hay que ir todavía a 
otra tienda más: una que ayuda a localizar qué es lo que anda mal. 


Preparación de un programa PASCAL 


De un modo más específico, la sucesión exacta de operaciones para la pre- 
paración de un programa PASCAL es la siguiente: 
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1) Se escribe el programa PASCAL en un archivo. Ello se hace usando un 
editor, que es adecuado tanto para la preparación de programas nuevos 
como para modificar programas que existan ya en un archivo. 


2) Tras dejar el editor, se introduce el archivo en un compilador. Este com- 
prueba si el programa contiene errores en el uso del PASCAL. Si hay al- 
gún error, se vuelve al paso 1) y se usa el editor para corregir el programa. 
Si no hay errores, el compilador crea un nuevo programa objeto, que es 
una versión ejecutable del programa fuente original. 


3) Se ejecuta el programa objeto. 


4) Si el programa se para o interrumpe a causa de un error, tal como una 
división por cero o un subíndice ilegal, es posible que haya que entrar en un 
debugger o depurador que nos ayude a averiguar qué es lo que marcha mal. 


Más adelante, en el curso de este capítulo, tendremos ocasión de estudiar 
en forma más detallada estas cuatro fases. 

La idea importante que interesa retener es que el PASCAL sólo define lo 
que ocurre en los pasos o fases 2) y 3). El editor es un programa completamen- 
te independiente, que no está ligado en forma alguna al PASCAL; el editor 
puede emplearse indistintamente para escribir o editar programas en otros len- 
guajes de programación, o incluso textos en lenguaje corriente o datos numé- 


ricos. Igualmente, el depurador o “*“debugger”” es un programa independiente, 
aunque en algunos sistemas se halla más ligado al PASCAL que el editor. 


Sistemas operativos 


El control fundamental del ordenador y de sus periféricos reside en un siste- 
ma operativo. Los dos componentes más importantes de un sistema operativo 
son su sistema de archivo, que se ocupa de nuestros archivos, y su lenguaje 
de mando, el cual (entre otras cosas) nos permite seleccionar cualquiera de las 
cuatro fases de la programación PASCAL antes mencionadas. Antes de estu- 
diar en detalle estos dos componentes, empezaremos por enunciar unos cuan- 
tos hechos: 


1) Los sistemas operativos y los editores varían mucho de unas máquinas a 
otras. Presentan al usuario unos interfaces que difieren radicalmente. 


2) Algunos sistemas operativos son gigantescos, llegando a ocupar muchos 
millones de bytes. 


3) Enlos últimos años, los sistemas operativos han ido haciéndose más fáci- 
les de usar. Normalmente, los que se hallan en los microordenadores son 
recientes y, por necesidad pequeños; los de los grandes ordenadores cen- 
trales están muchas veces influenciados por rasgos o características que 


quedaron anticuados ya en los años sesenta pero que, por razones de com- 
patibilidad, todavía permanecen en el sistema. Como resultado de ello, los 
sistemas operativos de los microordenadores suelen ser mejores, aunque 


menos potentes, que los de sus gigantescos parientes. 


4) Los sistemas operativos más grandes permiten que muchos usuarios ““com- 
partan el tiempo” (time-share) del ordenador, mientras que los sistemas 
más pequeños sólo pueden servir a un usuario en cada momento. 


La tendencia actual es a ir abandonando el time-sharing o reparto del tiem- 
po de máquina, y a ir utilizando cada vez más los ordenadores personales indi- 
viduales. Existe, sin embargo, otra tendencia hacia el abandono del ordenador 
personal aislado y hacia la formación de redes de ordenadores personales co- 
nectados en conjuntos. Los ordenadores de la red trabajan o funcionan inde- 
pendientemente, pero pueden intercambiar archivos de información y compartir 
equipos o dispositivos caros, tales como impresoras y máquinas de composi- 
ción tipográfica. 

Lo ideal en un sistema operativo sería que éste hiciese que el entorno de 
la explotación del ordenador pasase inadvertido hasta el punto de serle invi- 
sible al usuario, el cual no debería tener conciencia de la existencia de otros 
usuarios empleando el ordenador en tiempo compartido, ni de si un dispositi- 
vo determinado se halla conectado a su ordenador directamente o por inter- 
medio de una red... aunque, cuando se trate de recoger documentos produci- 
dos por una impresora, siempre viene bien saber dónde se encuentra situada 
ésta. Esperemos que los sistemas operativos de nuestros lectores se aproximen 
por lo menos a este ideal. 


Sistemas de archivo 


Para la mayoría de los usuarios, la tarea más importante que realiza un 
sistema Operativo es la de cuidarse de sus archivos, los cuales pueden estar al- 
macenados en uno o más discos o elementos análogos. A continuación se enu- 
meran los servicios o facilidades más importantes de un sistema de archivo: 


e Nombres. Si nuestro almacenamiento o memoria de reserva es capaz 
de mantener más de un archivo, hemos de disponer de un sistema 
para asignar un nombre a cada uno, de modo que siempre sea posi- 
ble especificar el archivo que se desea en cada momento. Usualmen- 
te, un nombre de archivo está formado por un identificador tal co- 
mo NOMINA o ENSEÑ|1, seguido posiblemente por una misteriosa 
prolongación que dice al usuario el tipo del archivo de que se trate; 
por ejemplo, NOMINA.PAS puede ser un programa PASCAL, y 
ENSEÑ1.BAS un programa en BASIC. Asociado con los archivos va 
un índice o directorio, que da los nombres de todos los archivos exis- 
tentes, por ejemplo, en un disco dado. 
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e Ordenes. El sistema operativo provee las órdenes o comandos que 
sean precisas para aquellas operaciones de archivo frecuentemente 
realizadas, tales como borrar, copiar o transferir a otro medio (por 
ejemplo, de disco a cinta). 


e Atributos. Frecuentemente, los archivos llevan asociados determina- 
dos atributos. En una máquina con usuarios múltiples, puede haber 
algunos atributos asociados con la protección. El usuario debe tener 
la posibilidad de dotar a sus archivos de atributos que impidan que 
amigos indiscretos o entrometidos los modifiquen o tal vez incluso 
los lean o curioseen. Otros atributos pueden estar asociados con la 
permanencia de un archivo. Algunos sistemas proveen la posibilidad 
de archivos temporales que se anulan o borran automáticamente al 
final de cada sesión; esto contribuye a impedir que el sistema de ar- 
chivo vaya almacenando una colección de cosas viejas e inútiles. Fi- 
nalmente, puede haber atributos asociados con el método de acceso. 
Los archivos pueden ser de acceso aleatorio (random-access), lo que 
significa que uno puede leer o elegir partes de ellos en cualquier or- 
den que desee; es algo semejante a un libro de referencia, como un 
diccionario o una guía telefónica, que normalmente no se leen de ca- 
bo a rabo, sino buscando determinadas voces o determinados nom- 
bres que se deseen consultar. Los archivos pueden, alternativamen- 
te, ser secuenciales (serial), lo que significa que para llegar a cual- 
quier punto hemos de empezar desde el principio y explorarlos en for- 
ma ordenada y consecutiva (secuencial) hasta alcanzar el punto de- 
seado. Hay, además de estos dos, otros muchos tipos de métodos de 
acceso, y ésta es una de las razones por las que algunos sistemas ope- 
rativos ocupan millones de bytes; sin embargo, aquí no nos vamos 
a preocupar de ellos. En la práctica, la mayoría de los archivos se 
utilizan como archivos secuenciales y, en realidad, el PASCAL es- 
tándar sólo administra archivos secuenciales. 


Lenguajes de mando (command languages) 


En cierto sentido, el BASIC contiene un lenguaje de mando, que está for- 
mado por palabras tales como RUN, SAVE y LIST. Sin embargo, son tan sim- 
ples que uno difícilmente pensaría que constituyen un lenguaje. 

Los sistemas operativos proveen lenguajes de mando que generalizan las 
órdenes o comandos encontrados en el BASIC, y proporcionan asimismo otros 
servicios o facilidades. En realidad, el lenguaje de mando es el interfaz funda- 
mental entre el usuario y los servicios o facilidades a su disposición. Muchos sis- 
temas operativos soportan varios lenguajes de programación, y los comandos 
u órdenes están diseñados de modo que sean adecuados para todos los lengua- 


jes. Por consiguiente, el PASCAL puede ser uno de tantos lenguajes, y las ór- 
denes pueden no haber sido diseñadas pensando especificamente en el PASCAL. 

Algunos lenguajes de mando son de una complicación y una verbosidad in- 
creíbles: acerca de algunos se han escrito libros enteros. Si ves que el ordena- 
dor que piensas usar tiene un lenguaje de mando descrito en un manual de usua- 
rio de 400 páginas, ejecuta el siguiente programa PASCAL: 


open(ventana)); 
repeat 
if bastantefuerte(usted) then 
begin 
coja(manual); 
arroje(manual, ventana); 
end; 
seleccionarnuevo(ordenador); 
until pequeño(manual); 


Este programa, dicho sea de paso, introduce algunos conceptos de PAS- 
CAL que no hemos explicado todavía, pero esperamos que hayas cogido la 
idea básica de lo que se pretende. 

Incluso cuando se trata de un lenguaje de mando sencillo, la mayor parte 
de los programadores se ven obligados a seguir aquella máxima defensiva que 
dice: no te aprendas el lenguaje entero, sino sólo las órdenes o comandos sufi- 
cientes para ir arreglándotelas. (Posiblemente ya hayas hecho esto si has usa- 
do el BASIC con un sistema operativo, pero con el PASCAL será necesario 
que amplíes tu repertorio un poco más.) Ordenes o comandos típicos que po- 
drías necesitar conocer son los siguientes; recuérdese, sin embargo, que los len- 
guajes de mando varían inmensamente, de modo que es posible que tu sistema 
Operativo no se parezca en nada a esto. 


EDIT filename pasa al editor para trabajar en el archivo citado. 

PASCAL filename compila el programa PASCAL contenido en el archi- 
vo citado. 

RUN ejecuta el último programa compilado. 

DEBUG pasa al depurador para arrojar luz sobre lo que ocu- 


rrió durante la ejecución más reciente. 


Niveles de comunicación 


Un punto que da lugar a cierta confusión inicial entre los programadores 
de BASIC es que usualmente un sistema operativo ofrece diferentes niveles 
de comunicación. Cuando el BASIC nos pide una línea, podemos escribir un 
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comando o una línea de un programa. Cuando estamos usando un sistema ope- 
rativo y un editor para preparar un programa PASCAL, puede haber tres ni- 
veles de comunicación separados: 


1) Inicialmente estamos en el estado de mando (command status) en el siste- 
ma operativo. Aquí, la única cosa que podemos escribir es una de las ór- 
denes del lenguaje de mando, para decirle al sistema lo que tiene que ha- 
cer a continuación. La orden o comando puede ser del tipo simple y autó- 
nomo, como la supresión o borrado de un archivo. En este caso, el siste- 
ma operativo obedece la orden y vuelve inmediatamente al estado de man- 
do. Alternativamente, la orden dada puede ser una que pase el control a 
otro sistema, como la orden EDIT para pasar al editor. 


2) Si pasamos al editor, entramos en el estado de mando del editor. Entonces 
hemos de escribir una de las órdenes o comandos que nos proporciona el 
editor, como puede ser una orden para insertar texto. Más adelante co- 
mentaremos las órdenes o comandos del editor. 


3) Si escribimos una orden o comando para insertar texto, pasamos al estado 
de entrada de datos. Entonces escribimos el texto adecuado, en nuestro 
caso, un trozo de programa PASCAL. Al final del texto, se escribe un ca- 
rácter de control que finalice la entrada de datos y nos devuelva al nivel 2). 


Cuando hayamos terminado nuestro trabajo de edición, escribiremos un 
comando u orden de ““fin””, para volver al estado de mando del sistema opera- 
tivo (es decir, al nivel 1)). A estas alturas, nuestro programa PASCAL deberá 
estar almacenado en un archivo. A continuación escribimos una orden que ha- 
ga que nuestro programa se compile. Anteriormente hemos mencionado esta 
orden como PASCAL filename. 

Los sistemas operativos y los editores son un ganado tan díscolo que todo 
lo que digamos acerca de ellos, por muy generales que sean los términos en 
que hablemos, tendrá numerosas excepciones. Existen, por ejemplo, algunos 
sistemas que no siguen la jerarquía de tres niveles que acabamos de mencio- 
nar. Hay editores en los que las órdenes o comandos se diferencian de los da- 
tos pulsando la tecla de control del teclado cuando queremos especificar que 
se trata de una orden; de otro modo, todo lo que escribamos será tratado co- 
mo datos a insertar. Otros sistemas permiten el uso de comandos de nivel 1) 
en el nivel 2). A pesar de todo, nuestros tres niveles, aun cuando sean sólo 
conceptuales, pueden contribuir a clarificar tus ideas. 


Puntos varios 


La mayoría de los sistemas operativos modernos, y los lenguajes de mando 
asociados con ellos, ofrecen al usuario la comodidad de la independencia de 


dispositivos. Esto significa que si una orden produce alguna salida, podemos, 
según nuestros deseos, enviar esa salida a un archivo, a nuestra terminal, o 
a una impresora. La realización de la orden o comando es independiente del 
dispositivo que usemos. Un mecanismo similar es aplicable a las órdenes o co- 
mandos que impliquen entradas. 

Una orden para que se compile o ejecute un programa PASCAL puede im- 
plicar a muchos “archivos”? de entrada y/o de salida. Un sistema dotado de 
independencia de dispositivos es una gran ventaja porque nos permite, cuando 
sea necesario, modificar la dirección en que se encaminan estos archivos. 

Además del sistema de archivos y del lenguaje de mando, un sistema ope- 
rativo puede tener otros servicios o facilidades que necesitas conocer. Tal vez 
tengas que hacer tu presentación al sistema al principio identificándote (nom- 
bre y clave o contraseña secreta), y despedirte al final. Pueden existir rutinas 
contables, que te facturen el importe de la utilización del ordenador. Puede 
haber también programas de utilidades o servicios, que ejecutan tareas tales 
como la limpieza de archivos, o la preparación de discos para su uso. Si tienes 
suerte, habrá una orden o comando HELP (ayuda), que te proporcionará ase- 
soramiento cuando te metas en dificultades. 

Finalmente, la cosa más importante que hay que saber antes de iniciar cual- 
quier tipo de programación es la forma de parar si las cosas se te van de las 
manos, por ejemplo, si tu programa se mete en un ciclo infinito de salida. To- 
do sistema operativo tiene una tecla de interrupción o ruptura que se puede 
utilizar para abortar la actividad en curso. Normalmente, esta tecla ocasiona 
un retorno al estado de mando en el seno del sistema operativo. Antes de em- 
pezar a ejecutar tus programas, averigua la forma en que se puede hacer la 
ruptura. 


Editores 


Ahora que ya hemos descrito brevemente los sistemas operativos, haremos 
algo análogo con los editores. 

El de la edición es un concepto sencillo. Incluye la creación de un archivo 
y el cambio o modificación de su contenido. Básicamente, sólo hay tres opera- 
ciones posibles: borrado o supresión, inserción y sustitución. El trabajo de edi- 
ción es tan sencillo, en efecto, que cualquier programador de sistemas puede 
escribir un editor. La mayoría lo han hecho. El resultado es que existen miles 
de editores diferentes, ninguno de los cuales ha conseguido el predominio. 

La gente es muy exigente y especial en el tema de los editores que usa. Es 
una característica del hombre (incluyendo, desde luego, a la mujer) que, cuan- 
to más triviales son las cuestiones, más obstinadamente se aferra a su opinión. 
Así, hay gente que se emperra en usar un determinado editor porque emplea 
la S para indicar sustitución, y no otro que, en forma equivalente, use la C 
para indicar cambio. A causa de este prejuicio, algunos grandes ordenadores 
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que prestan servicio a cientos de usuarios tienen que mantener activos cientos 
de editores. 

Si nunca has hecho uso de un editor antes de ahora, cuidado. Una vez que 
hayas aprendido tu primer editor, nunca volverás a ser la misma persona ex- 
tremadamente razonable que eras. (El sistema empleado en el BASIC de usar 
los números de línea para especificar dónde ha de hacerse un cambio, por ejem- 
plo escribiendo 


100 LETX =0 


para sustituir a una línea 100 ya existente, es en cierto modo un editor, de ma- 
nera que tal vez sea ya demasiado tarde para avisarte. Es más, algunos BASIC 
permiten desplazar un cursor sobre una pantalla para hacer modificaciones es- 
pecíficas dentro de una línea.) 

Explicaremos algunas de las características generales de los editores. Los 
detalles (y, como hemos advertido, aquí es donde empiezan las dificultades) 
tendrás que consultarlos en el manual local de tu editor. 


Rasgos o características de los editores 


Lo primero que ha de hacer un editor es facilitarnos un medio para especi- 
ficar en qué lugar del archivo deseamos introducir un cambio. Algunos edito- 
res antiguos exigían que los cambios se hicieran en el mismo orden en que se 
producían dentro del archivo (por ejemplo, si hubiéramos cambiado la línea 
décima, ya no podríamos hacer cambios en la novena), pero pocos de esos edi- 
tores permanecen activos. Ahora, en cambio, el editor hace que el archivo a 
editar se parezca a uno de acceso aleatorio, aun cuando el archivo subyacente 
sea realmente del tipo secuencial. Existen tres formas básicas para especificar 
el lugar en que se han de hacer cambios: 


1) Por los números de línea. Se trata del método menos atractivo. Uno dice 
algo así como ““quiero cambiar la línea cincuenta y nueve””. Si el archivo 
que se ha de editar es largo, éste es un método impracticable, a menos que 
tengamos un listado de aquél que lleve marcados los números de línea. Ob- 
sérvese que estos números de línea no son como los del BASIC, porque 
estos últimos están realmente en el texto del programa, mientras que los 
números de línea a los que nos referimos no lo están. 


2) Por el contexto. Aquí tenemos el concepto de un punto de exploración que 
ha de desplazarse al lugar en el que haya de introducirse el cambio. Para 
hallar una línea determinada escribimos una cadena de caracteres que es- 
peramos se produzca únicamente en aquella línea. El editor parte del pun- 
to actual de exploración y busca en forma secuencial hacia adelante (u, 


optativamente, hacia atrás) hasta encontrar una línea que contenga la ca- 
dena de caracteres deseada. Entonces presenta visualmente esta línea, que 
se convierte así en el punto de exploración. Podríamos, por ejemplo, pe- 
dir al editor que halle una línea que contenga la cadena ““x+ 3;””. El editor 
se desplazaría desde el punto de exploración actual hasta que hallara di- 
cha línea, y entonces la presentaría visualmente. La línea podría ser 


cuenta: =x +3; 


Si ésta fuera la línea que quisiéramos, ahora estaríamos listos para intro- 
ducir nuestro cambio. Sin embargo, si estuviera antes de la línea que de- 
seábamos, podríamos continuar buscando la misma cadena, partiendo de 
este nuevo punto de exploración. 


3) Situando un cursor. El más agradable de los métodos de edición consiste 
en señalar el lugar del programa en el que se desea introducir cambios. 
Posiblemente estés ya familiarizado con este método por haberlo usado 
en tu sistema BASIC. Para él es necesario disponer de un display, o pre- 
sentación visual, con un cursor móvil. Lo más reciente en materia de edi- 
ción consiste en disponer de un indicador o puntero electrónico —hay uno 
conocido como “ratón”? — que se puede utilizar para desplazar el cursor 
sobre la superficie de la pantalla; es tan bueno que incluso los más llenos 
de prejuicios terminarán adoptándolo. La alternativa es mover el cursor 
sobre la pantalla pulsando en el teclado las teclas adecuadas. 


Si tienes un programa de cierto tamaño (aunque sea pequeño), no en- 
trará en una pantalla. Entonces puedes considerar que ésta es una ventana 
por la que se ve parte de tu archivo. Para desplazar la ventana a otra parte 
del archivo puede ser preciso usar la edición por contexto. Alternativa- 
mente, algunos editores realmente sofisticados permiten indicar en qué lu- 
gar del archivo ha de quedar la ventana mediante el desplazamiento del 
cursor a lo largo de una escala presentada visualmente en algún lugar de 
la pantalla. 


. y 


Ordenes o comandos de edición 


Una vez que hayamos encontrado el lugar del programa que se ha de modi- 
ficar, estaremos preparados para escribir una orden de edición y realizar final- 
mente dicho cambio. Las órdenes más frecuentes son las fundamentales: in- 
serción, supresión y sustitución. Estas órdenes pueden actuar sobre líneas com- 
pletas de texto, o sobre subcadenas dentro de una línea. 

A lo largo de los años, la tienda del editor (por volver a nuestra primera 
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analogía) ha ampliado la línea de productos que ofrece a sus clientes. Así, los 
editores modernos se pueden usar también para hacer operaciones tales como 
las siguientes: 


e Sustituir por otra una cadena de caracteres cada vez que aparezca, 
alo largo de todo un archivo. Por ejemplo, podríamos hacer uso del 
editor para sustituir el nombre de variable scnt por shipcount. 


e Insertar algún texto almacenado en otro archivo. 
e Trasladar texto de una parte a otra. 
e Buscar una determinada combinación de caracteres todas las veces 


que se produzca. 


Esta diversidad da a los editores muchas probabilidades de diferenciarse 
entre sí, y hay que decir que han aprovechado plenamente esta posibilidad. 


Displays o sistemas 
de presentación visual perfeccionados 


Cuando se está trabajando con información escrita sobre trozos de papel, 
suele ser conveniente tener ante la vista varias hojas al mismo tiempo. Al tra- 
bajar en un programa, por ejemplo, podemos tener el manual del usuario abierto 
en una página determinada, de modo que sea posible compararlo con un lista- 
do del programa y con la impresión de un mensaje de error que se haya produ- 
cido al ejecutar dicho programa. Trabajaremos fijando la vista alternativamente 
en las tres hojas de papel. 

En la actualidad muchas veces es difícil hacer lo mismo cuando se utiliza 
la pantalla de un ordenador en lugar de hojas de papel. Sin embargo, una de 
las tendencias más felices e importantes de los últimos años es la producción 
de sistemas de presentación visual en pantalla cada vez más potentes, los cua- 
les, en conjunción con un software fácil de usar, nos permiten comunicarnos 
más fácilmente con los ordenadores. Ahora hay sistemas en los que es posible 
presentar en la pantalla varias ventanas separadas, y moverlas a un lado y a 
otro exactamente como si fuesen trozos de papel sobre una mesa de trabajo. 
Teitelman (1977) describe un magnífico sistema de este tipo. 

Aunque tal vez resulte sorprendente, los sistemas de presentación visual que 
se encuentran en ordenadores personales baratos son a menudo más potentes 
que los conectados a grandes ordenadores que cuestan cientos de veces más. 
La razón de ello es que los costosos ordenadores de tiempo compartido son 
demasiado valiosos para dedicar su tiempo a ocuparse de una pantalla de pre- 
sentación visual. Sin embargo, este fenómeno está desapareciendo ya, a medi- 


da que se van haciendo más comunes las redes flexibles de ordenadores espe- 
cializados. 

La razón por la que nos hemos ocupado con cierta extensión de las presen- 
taciones visuales es que, a medida que el trabajo de edición se va haciendo más 
sencillo, las diferencias entre la edición en PASCAL y la edición en BASIC 
pueden ir disminuyendo. El sistema utilizado por el BASIC, de usar los núme- 
ros de línea para editar, puede caer en desuso si resulta más fácil editar un 
programa señalando a una ventana sobre un display. 


Utilización de un compilador de PASCAL 


Una vez preparado o modificado nuestro programa mediante el uso de un 
editor, entramos en el compilador de PASCAL escribiendo un comando tal 
como 


PASCAL filename 


La mayor parte de los compiladores de PASCAL son completamente no- 
interactivos. Simplemente, uno les entrega un archivo y luego se sienta a espe- 
rar que salgan los mensajes de error. En el PASCAL sacarás muchos más errores 
de los que solías sacar en BASIC. Ello es así por tres razones: 


1) El PASCAL es un lenguaje más elaborado. 


2) En el PASCAL, un solo error puede dar origen a toda una multitud de 
mensajes. Si se te ha olvidado declarar una variable, puedes recibir un men- 
saje de error cada vez que se utilice dicha variable. Además, ciertos erro- 
res hacen que algunos compiladores de poca calidad se hagan un lío, de 
manera que dan varios errores falsos detrás de cada uno real. Así, algunas 
veces hallarás que, cuando cortiges un error, los “errores” siguientes pue- 
den desvanecerse en forma mágica. 


3) Dado que los compiladores de PASCAL no son interactivos, es muy fácil 
cometer el mismo error muchas veces. En un nivel elemental, podrías olvi- 
darte del punto y coma después de cualquier sentencia, y no sabrías nada 
de tu equivocación hasta que compilases todo el programa. 


Por consiguiente, no desmayes cuando tu primer programa PASCAL, que 
ocupará tal vez diez líneas, genere veinte mensajes de error. 

Un problema particular es el ocasionado por la facilidad que tiene el PAS- 
CAL para las construcciones que ocupan varias líneas, por ejemplo: 


(x* un comentario 
de dos líneas x) 
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Si se te olvida el carácter *“x)”” que pone fin a un comentario u observa- 
ción, el compilador escudriñará todo el programa para encontrar la ““x)”” si- 
guiente, haciendo caso omiso de todo aquello sobre lo que pase. El resultado 
de ello puede ser una serie de desconcertantes mensajes de error. Problemas 
análogos pueden desprenderse de la omisión de comillas en strings o cadenas 
de caracteres, o de la de end. Por tanto, si hallas mensajes de error especial- 
mente enigmáticos, explora estas posibilidades. 

Cuando hayas llegado a la fase en que seas capaz de producir un programa 
correcto, el compilador PASCAL traducirá tu programa en un programa ob- 
jeto. Este es el que ejecutas con RUN. Los programas objeto se pueden ejecu- 
tar tantas veces como se quiera. Una vez que tenemos un programa que fun- 
ciona, no hay necesidad de compilarlo cada vez que se desee usarlo, ya que 
casi todos los sistemas PASCAL proporcionan la forma de conservar (SAVE) 
programas objeto en el sistema de archivo. 


Ejecución de un programa PASCAL 


Hemos supuesto que para ejecutar un programa PASCAL escribimos la 
orden 


RUN 


(RUN —o EXECUTE, como lo llaman algunos sistemas— podría ir seguido 
opcionalmente por el nombre de un programa objeto si quisieras ejecutar uno 
que no fuese el compilado más recientemente.) Algunos sistemas PASCAL ini- 
cian automáticamente la ejecución si la compilación se ha completado en for- 
ma satisfactoria. Para ellos, la orden RUN es innecesaria. 

La ejecución de un programa PASCAL es igual que la de uno en BASIC, 
hasta que las cosas van mal. Cuando se tiene un error en la ejecución (run- 
time error) o una ruptura, el PASCAL revela su naturaleza no-interactiva: nor- 
malmente, hace un listado (dump) de los nombres de todas las variables (ex- 
cluyendo arrays o matrices y cosas análogas) y de los valores de aquéllas cuan- 
do se produjo el error. A continuación, abandona la ejecución. Entonces, uno 
utiliza el listado (dump) para tratar de descubrir qué es lo que ha pasado. 


Depuradores o debuggers 


Algunos sistemas operativos proveen sistemas depuradores interactivos, que 
se pueden usar en los programas PASCAL. Varios de éstos tienen prestacio- 


nes similares a las encontradas en los buenos BASIC, por ejemplo declaracio- 
nes inmediatas. 

Cualquier sistema depurador o debugger decente debe comunicarse con el 
usuario en términos de lenguaje fuente, es decir, en términos del programa que 
aquél escribió, y no en alguna representación interna que a él no debe intere- 
sarle. Sin embargo, todavía andan por ahí muchos sistemas depuradores que 
no son decentes, así que ya te puedes preparar a tener que aprender horribles 
detalles internos. 

Algunas veces, un sistema depurador está integrado con la ejecución de pro- 
gramas, y proporciona facilidades tales como la traza o seguimiento (tracing), 
O la ejecución del programa sentencia por sentencia (una de cada vez). 

Estas generalidades, un tanto vagas, son todo lo que podemos decir acerca 
de los sistemas depuradores. Su diversidad es tan grande que no serviría de 
nada entrar en más detalles. 


Casos especiales 


Como no hemos dejado de repetir a lo largo de este capítulo, uno de los 
placeres, y de las frustraciones, del software de ordenadores es que tanto sus 
filosofías básicas como los detalles de menor cuantía varían mucho. Los hay 
completamente heterodoxos y diferentes a los demás, y, a lo largo de los años, 
algunos de ellos han alcanzado tanto éxito que han llegado a convertirse en 
ciudadanos integrados en la comunidad del software y a gozar de gran predi- 
camento en ella. 

Aunque el BASIC es normalmente un lenguaje interactivo y el PASCAL 
no, ha habido excepciones. Los BASIC no interactivos son algo así como pá- 
jaros sin alas, y probablemente se extinguirán pronto. En cambio, los pocos 
intentos que se han hecho con los sistemas PASCAL semiinteractivos son más 
prometedores. 

Hay además unos cuantos editores que están diseñados especialmente para 
ocuparse en forma exclusiva de programas PASCAL. Algunos de ellos están 
destinados a ayudar al usuario a preparar programas sintácticamente correc- 
tos. Véase, por ejemplo, el COPAS (Atkinson € North, 1981) o The Cornell 
program synthesizer (El sintetizador de programas Cornell, Teitelbaum « Reps, 
1981). 

A pesar de la importancia potencial de estos casos anómalos, no les presta- 
remos mucha atención en el resto de este libro, sino que seguiremos concen- 
trándonos en el caso más sencillo y frecuente. 


La opinión de un experto 


Cuando fuimos a pedir a Bill Mudd su opinión acerca de los sistemas ope- 
rativos, estaba todavía en su terminal trabajando en su ingenioso e inteligente 
programa BASIC. Acababa de sustituir 


1096 GOSUB 4305 
por 
1096 GOSUB 4605 


pero el programa seguía todavía sin funcionar. Tal vez esto explique su estado 
de ánimo, más bien agrio. 


““En el BASIC, el cambiar tu programa y ejecutarlo de nuevo es una 
cosa trivial”, dijo. ““Sólo en este pequeño programa, he hecho yo unos 
cincuenta cambios y he repetido la ejecución otras tantas veces. Y ahora 
vienes a pedirme que pierda cinco minutos liado con sistemas operativos 
y editores para cada cambio.”” 

““Sin embargo””, continuó mientrás introducía un nuevo ajuste en su 
programa, “me gusta realmente un comentario que has hecho: el conse- 
jo relativo a tirar por la ventana el manual si es demasiado grande. Y 
estoy observando que tu libro es ya bastante grande.”” 


ERROR 
IAELIG50: UN 


Amigos míos, no volveremos ni remedaremos una antigua rabia, ni alargaremos 
la locura de nuestra juventud para que se convierta en la vergúenza de la vejez. 


G.K. CHESTERTON 


Traducción 


de conceptos 
del BASIC 


Ahora ya hemos terminado con la información básica y preliminar, y vamos a 
dedicar el resto de nuestro libro a una descripción bastante completa del PASCAL. 

No obstante, no queremos que el libro sea sólo un catálogo sistemático de 
rasgos y características del lenguaje. En lugar de ello, empezaremos con caracte- 
rísticas que ya te son conocidas por el BASIC, y trabajaremos a partir de ellas. 
Los conceptos nuevos del PASCAL se introducirán a medida que surjan natural- 
mente en los ejemplos, más bien que en la posición impuesta tal vez por el infor- 
me PASCAL. 

En este capítulo nos concentraremos en las sentencias individuales y en los 
constituyentes básicos que las forman, y en el capítulo próximo continuaremos 
con las subrutinas y las funciones. Ya hemos tratado en el capítulo 1 de las sen- 
tencias de asignación y de los rudimentos de la entrada/salida. (La sencilla sen- 
tencia de asignación empleada en el capítulo 1 es todo lo que ofrece el PASCAL 
en este aspecto. No hay sentencias de “asignación mútiple”” como la 


LETA=B=0 
que poseen algunos BASIC.) 
Si deseas consultar la definición sintáctica precisa o exacta de cualquier sen- 


tencia PASCAL, mira el Apéndice C. 
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El espaciado y los comentarios u observaciones 


Empezaremos, al nivel más bajo posible, con las reglas para la disposición 
de los programas PASCAL. Como ocurre en BASIC, se pueden añadir libremente 
los espacios que se quiera entre los símbolos de un programa para mejorar la dis- 
posición o presentación gráfica del mismo. En el PASCAL es obligatoria la in- 
serción de un espacio para separar dos palabras o números adyacentes, por ejem- 
plo en 


for y COUnt:=Y 4 10 +4 6 1 do 


es necesario que haya por lo menos un espacio en cada uno de los cuatro lugares 
marcados por las flechas. No se permite la existencia de espacios dentro de los 
números o palabras. 

Como se mencionó en el capítulo 1, el final de una línea se trata exactamente 
igual que un espacio. 

También se trata como si fuera un espacio cada observación o comentario, 
que en el PASCAL se encierra entre llaves ** ( ” y “+” como ya hemos visto. 
(Pueden usarse los símbolos ““(+*”” y “*x)”” como alternativas para las llaves de 
apertura y cierre “*f” y ““/” si éstas no existen en nuestro teclado.) Los co- 
mentarios u observaciones pueden abarcar cualquier número de líneas, y produ- 
cirse en el interior de sentencias, por ejemplo: 


for count:= y to 6 (x* se para en 6 porque... «*) do 


Nombres 


Para nombrar un objeto, tal como una variable, se elige un identificador. Un 
identificador es una letra seguida de una sucesión de letras y/o cifras de longitud 
arbitraria. Normalmente, las letras minúsculas se tratan como diferentes de las 
mayúsculas. A continuación se dan algunos ejemplos de identificadores: 


x, x1,Southampton6SpursO 


No eches en saco roto el consejo que te hemos dado: olvida el hábito del BA- 
SIC de usar nombres cortos; en lugar de ello, procura elegir nombres explícitos 
y con significado. Los identificadores formados por varias palabras se pueden 
hacer más legibles si el compilador permite el uso de mayúsculas y minúsculas, 
mediante el empleo de mayúsculas para las letras iniciales de las palabras. Por 
ejemplo, NombreDeCuatroPalabras es más legible que nombredecuatropalabras. 


(En este libro, sin embargo, hacemos un uso bastante avaro de las mayúsculas 
en PASCAL, pero ello obedece únicamente a la convención que hemos adoptado 
de usar las mayúsculas para representar elementos o entidades de BASIC.) 

Algunos compiladores de PASCAL sólo tienen en cuenta los ocho primeros 
caracteres de un identificador. Si en lugar de escribir Southampton6Spurs0 hu- 
biéramos tecleado Southampton0Spurs6, esos compiladores no habrían aprecia- 
do ninguna diferencia. 

Los identificadores no han de contener ningún espacio. (*“Yo creí que los nom- 
bres empleados en PASCAL debían tener un significado claro”, dijo Bill. “Nues- 
traconversaciónnotendríaunsignificadomuyclarosinopudiéramosusarespacios.””) 

Todas las palabras que forman parte de la sintaxis del PASCAL (tales como 
var, for, to, etc.) reciben el nombre de palabras reservadas. Estas son las pala- 
bras que, por razones de legibilidad, se imprimen convencionalmente en negritas 
cuando en un libro se incluyen programas de PASCAL. No se puede elegir como 
identificador una palabra reservada. La lista completa de las palabras que no han 
de usarse en esta forma es: 


and donwnto if or then 
array else in packed to 
begin end label procedure type 
case file mod program until 
const for nil record var 
div function not repeat while 
do goto of set with 


No te molestes en recordarlas todas; si alguna vez eliges por casualidad una 
de ellas para un identificador, el PASCAL te lo avisará muy pronto. 


Tipos de datos 


Antes de ponernos a considerar las sentencias individuales de BASIC, vamos 
a entretenernos en un área cubierta por el PASCAL, pero no por el BASIC: la 
de los tipos de datos definidos por el usuario y los tipos de datos de subconjunto 
o subrango. Nuestra finalidad al ocuparnos de esto en este momento es hacer 
que los ejemplos venideros resulten más ilustrativos. 

El PASCAL nos permite definir nuestros propios tipos de datos. El hacerlo 
no es solamente una buena costumbre; es también algo divertido. Existe un goce 
creativo en hacer algo que, en la mayoría de los lenguajes, es imposible. 

A fin de proveer algo de pasto o forraje para este capítulo y los siguientes, 
vamos ahora a definir algunos tipos de datos nuestros y completamente nuevos, 
para complementar los tipos, tales como real e integer, incorporados en el PAS- 
CAL. Estos tipos definidos por el usuario se declaran en la forma siguiente: 


type 
howout = bowled, caught, stumped, runout, lbw; 


La declaración de type precede inmediatamente a la de var. 

Para aquellos lectores que desconozcan el juego del cricket, convendría expli- 
car que el tipo de datos definidos por el usuario que acabamos de relacionar es 
una lista de las formas en que se puede eliminar o dejar fuera a un bateador. 
Podría utilizarse en un programa para la simulación de dicho juego. Desde lue- 
go, para la ejecución de tal programa sería necesario reducir en muchos órdenes 
de magnitud la velocidad del ordenador, a fin de acomodarla al tempo propio 
de este juego. 

Cada tipo definido por el usuario es una sucesión de identificadores que re- 
presenta a todas las constantes de dicho tipo. Así, las constantes del tipo howout 
(formelim) son bowled (derribado), caught (cogido)... /bw (piernaantelaportería). 
Estas constantes son analogías exactas de las constantes 1, 2, 3..., del tipo entero 
(integer). El objeto de un tipo definido por el usuario es hacer que el programa 
sea más legible. Una vez que se ha declarado un tipo, se pueden definir ya las 
variables correspondientes al mismo. Por ejemplo, se puede declarar a un bateador 


var 
bateador: howout; 


La variable bateador puede tomar cualquiera de los valores de nuestro con- 
junto; en realidad, éstos son los únicos valores que puede tomar. Así, podemos 
decir 


bateador: = bowled, 


Esto es muchísimo mejor que el estilo que el Sr. 869704 impone a los progra- 
madores de BASIC, consistente en representar bowled, caught, etc., por medio 
de números arbitrarios. 

Obsérvese que los tipos definidos por el usuario que emplea el PASCAL son 
completamente diferentes de los enteros (integers), en la misma forma en que las 
cadenas o strings difieren de los enteros en BASIC. Por consiguiente, no se puede 
decir bowled+ 1, ni poner un bateador a cero. 

(En la literatura del PASCAL es frecuente llamar a los tipos definidos por 
el usuario tipos escalares o enumerados.) 


Tipos subrango 


El PASCAL nos permite definir un tipo de datos que es un submargen o sub- 
rango de un tipo de datos existente. Por ejemplo, la declaración de tipo 


enteropositivo = 1..maxint; 


declara que enteropositivo es un nuevo tipo que constituye un subrango del tipo 
existente entero (integer). Este subrango empieza en el entero 1 y llega hasta ma- 
xint, el cual es una constante incorporada en el PASCAL, que representa el nú- 
mero entero más alto que pueda soportar nuestro compilador. Así, nuestro tipo 
subrango, como su nombre indica, está formado sólo por enteros positivos. Si 
a una variable de este tipo se le asignase un valor negativo o cero, ello sería un 
error. 
Otros ejemplos de subrangos son: 


(* El tipo que sigue consta de los 11 valores posibles: —5, —4,..., 4, 5, x) 
enteropequeño = —5..5; 

(x* El tipo que sigue excluye a lbw, que frecuentemente es objeto de 
discusion x) 
fuerasinduda = bowled..runout; 


Los subrangos tienen tres usos principales. Primero, y más importante, se pue- 
den usar para dar seguridad a un programa. Si Perkins sabe que en un determi- 
nado lugar se espera un entero positivo, cuando aparezca un entero negativo po- 
drá eliminarlo y descartarlo inmediatamente como espúreo. En segundo lugar, 
los tipos de subrango pueden ser empleados por un compilador para ahorrar es- 
pacio de almacenamiento; un compilador podría, si le gustara la idea, almacenar 
un enteropequeño en un solo byte, o incluso en cuatro bits. En tercer lugar, los 
tipos subrango tienen un valor inapreciable para límites de arrays o matrices, 
como veremos. 

Los tipos subrango son compatibles con los tipos que les incluyen. Ello signi- 
fica, por ejemplo, que en todo lugar en que se pueda utilizar una variable entero 
o integer, se puede usar también una variable enteropequeño o enteropositivo. 
(Existe una pequeña excepción, de la que hablaremos en el capítulo próximo, cuan- 
do introduzcamos los “parámetros variables””.) 

Como ejemplo del trabajo de Perkins con los tipos de subrango, considere- 
mos la sentencia 


p:= q —10; 


en la que p es un enteropositivo y q es un enteropequeño. El valor de q no puede 
ser superior a 5 y, por tanto, q —10 ha de ser negativo; así, el efecto de la senten- 
cia sería tratar de igualar p a valor negativo, de modo que Perkins dé un mensaje 
de error. Algunos compiladores son suficientemente inteligentes para coger tales 
errores cuando se compila un programa, evitando así la molestia segura de com- 
probar al tiempo de la ejecución. Sin embargo, en la mayoría de los casos ha 
de hacerse la comprobación en la fase de ejecución; por ejemplo, en la sentencia 


p:= q; 


ha de hacerse una comprobación en la fase de ejecución para asegurarse de que 
el valor asignado a p es positivo. 
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En cierto sentido, un tipo subrango es un tipo definido por el usuario; al fin 
y al cabo, el usuario lo define. Sin embargo, está basado en un tipo existente, 
y hemos reservado el término tipo definido por el usuario para aquellos que, co- 
mo el howout, se definen desde cero. 


Declaraciones 


Todos los objetos del PASCAL, aparte de las constantes numéricas y las de 
cadena o string, se representan por medio de identificadores. En todos los casos, 
ha de haber una declaración de lo que significa el identificador. Así, en 


type 
t = (ctl, ct2); 
var 
vl: integer; 
v2: t; 


se declara que el identificador f es un tipo; que cfl y cf2 son constantes del tipo 
ty y que vl y v2 son variables. (La primera es un entero o integer, y la última 
es del tipo f.) Con una excepción, que se explicará más adelante, todos los identi- 
ficadores han de declararse antes de utilizarlos por primera vez. 

Si se declaran varias variables del mismo tipo, se las puede combinar para 
no tener que repetir el tipo. Así 


xl: integer; 
x2: integer; 
pig: integer; 


se puede escribir 


xl, x2, pig: integer; 


Funciones incorporadas 


El PASCAL, al igual que el BASIC, soporta un juego o conjunto de funcio- 
nes incorporadas, y estas funciones tienen identificadores que las nombran (por 
ejemplo, sin, cos). A diferencia de las palabras reservadas, estos nombres pueden 
ser utilizados por el usuario para sus propios identificadores. Así, tu programa 
porno más vendido puede tener una variable que se llame sin, aunque entonces 
el programa no podría usar la función sin del PASCAL... pero, de todas mane- 
ras, no querría usarla. (N. del T.: Nuevamente tenemos aquí un juego de pala- 
bras intraducible entre ““sin””, seno trigonométrico, y ““sin””, pecado. Tal vez se 


pudiera jugar en español con los dos significados de “seno”, el trigonométrico 
y el anatómico femenino.) (Las reglas aplicables a los nombres de los tipos incor- 
porados, tales como real e integer, y a las constantes incorporadas, tales como 
maxint, son similares.) 

La mayoría de las funciones incorporadas en el BASIC tienen equivalentes 
en PASCAL, aunque hay varias cuyos nombres son diferentes. La lista que sigue 
da las traducciones: 


BASIC PASCAL 
ABS abs 
ATN arctan 
COS cos 
EXP exp 
LOG In 

RND no existe 
SGN no existe 
SIN sin 

SQR sqrt 
TAN no existe 


Todas las funciones PASCAL precedentes toman o aceptan un argumento 
real y entregan un resultado real, excepto la abs, que se puede usar con números 
enteros (integers) o con reales. La función de BASIC INT es similar a la función 
que en PASCAL se denomina curiosamente trunc (este nombrt viene de ““trun- 
cate”, truncado); frunc sólo difiere de INT si el argumento es negativo: trunc 
(3,2) es —3, mientras que INT (—3,2) es —4. La función trunc da siempre 
un resultado entero o integer. 

Algunos PASCAL ampliados llenan las lagunas representadas por no existe 
en la tabla precedente. 

La peor noticia para el programador de BASIC es que el PASCAL tiene una 
función sqr que significa el cuadrado de su argumento, y no su raíz cuadrada. 
El perversamente nombrado Sr. Sqr es un tipo realmente malo. Si construyes un 
puente basándote en ciertos cálculos de PASCAL, y el puente se cae, mira a ver 
si has dejado entrar en tu programa al Sr. Sqr, cuando en realidad querías meter 
sqrt. 

Aunque resulte irónico, el sqr es el único atractivo adicional que el PASCAL 
ofrece entre sus funciones aritméticas estándar. 


Constantes 


Las constantes numéricas son idénticas en BASIC y en PASCAL, con la sal- 
vedad de que en este último siempre ha de haber por lo menos una difra delante 
de la coma decimal. Así, el ,1 del BASIC se convierte en el 0,1 del PASCAL. 
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Expresiones 
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En conjunto, las expresiones aritméticas son prácticamente iguales en PAS- 
CAL y en BASIC. Las pocas diferencias que hay son las existentes entre los tipos 
integer y real, y el uso del operador de potenciación. 

En una expresión en PASCAL se pueden mezclar números enteros (integers) 
y reales, y obtener los resultados esperados. Así, si se suman un entero y un real, 
se obtiene un real. Lo que se ha de evitar principalmente es asignar un valor real 
a una variable entera o integer; en lugar de ello, se puede emplear la función frunc 
para convertir el real en entero antes de hacer la asignación. El operador de la 
división **/”” siempre da un resultado real; si tenemos operandos enteros (integer) 
y queremos un resultado también entero, habremos de usar el operador div. Con 
ello se trunca el resultado, dejando sólo la parte entera. Así 


7div4es 1 
S div4es 1 
S / 4es 1,25 


El operador mod que, al igual que div, funciona con dos operandos integer, 
da el resto que queda cuando se divide el primer operando por el segundo. Así, 


5 mod 4es 1 
7 mod 4 es 3 


Si intentas escribir 
xly 


en PASCAL, la cosa no funcionará, porque el PASCAL no tiene operador de 
potenciación en absoluto. Lo que tienes que hacer es escribir 


exp *In(x) 


Sin embargo, si se trata de una potencia entera, puedes hallar alguna forma 
más eficiente. Así, la expresión BASIC 


x14 
se puede escribir en PASCAL, usando la perversa función sgr, 
sqr(sqr(x)) 


Como quiera que las funciones exp y In son de ejecución lenta, mientras que 
la sqr es relativamente rápida, la expresión precedente se ejecuta mucho más de- 


prisa que la forma más general. En realidad, la finalidad misma de la carencia 
de potenciación en el PASCAL es hacer que el usuario piense qué es lo que de 
verdad desea, y que entonces use el método más eficiente. 


Sentencias IF 


Ahora podemos pasar a considerar las sentencias BASIC individuales, y 
la primera de la que nos ocuparemos es la sentencia IF. 
Si estás acostumbrado a escribir sentencias IF tales como 


IF X = Y THEN 500 


necesitarás cambiar tu forma de pensar cuando pases al PASCAL. 

El problema no está en la expresión de relación existente entre IF y THEN 
(por ejemplo, en el caso anterior, X = Y), sino en lo que viene después de 
THEN. 

Para empezar por lo más fácil, las expresiones de relación del BASIC son 
iguales en PASCAL, aunque es posible mejorar el programa utilizando los me- 
dios más avanzados que el PASCAL posee a este respecto. En realidad, el PAS- 
CAL permite una construcción más general, conocida como una expresión de 
Boole, o Booleana allí donde el BASIC permite una expresión de relación. Más 
adelante estudiaremos esta construcción..., por el momento, piensa en ella co- 
mo en una expresión de relación. 

Los operadores de relación, a saber: 


se escriben igual en BASIC y en PASCAL. 
Y vamos con la gran diferencia. El PASCAL soporta dos formas de senten- 


cia if. Se escriben así: 


if <expresión de Boole> then < sentencia > 


if <expresión de Boole> then <sentencia> else < sentencia > 


La notación empleada es obvia. La sentencia que sigue a then se ejecuta 
si la expresión de Boole es verdadera (true), y la sentencia que sigue a else, 
si la hay, se ejecuta si la expresión de Boole es falsa (false). 
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No olvides que, en todas las situaciones del PASCAL en las que se necesite 
una sentencia, podemos meter varias sentencias encerradas entre un begin y 
un end. Hay una regla especial que ha de observarse en la sintaxis de las sen- 
tencias if: no se ponga nunca un “punto y coma”” delante de un else. En otros 
- casos, los ““punto y coma” sobrantes, dentro de un orden, no importan. (“Ya 
le dije a usted que había cometido un inmenso error en el capítulo 1, cuando 
les recomendó que pusieran punto y coma al final de todas las sentencias”, 
repetía el profesor Primple en un tono que indicaba que no toleraría ningún 
argumento en contra.) 

A continuación damos, a título de ilustración o ejemplo, un breve frag- 
mento de un programa en BASIC y su equivalente en PASCAL: 


100. IFX > Y THEN 150 

110 LETP =0 

120 GOTO 200 

150 LETP = 1 

160. PRINT “X ES MAYOR QUE Y”” 
200 


if x< =y then 
p:=0 (* ¡no pongas punto y coma aquí x) 
else 


writeln ("x es mayor que y”); 
end; 


Vale la pena insistir aquí de nuevo en que a los programas PASCAL se 
les puede dar cualquier disposición que nos guste. Se puede argúir que la dis- 
posición que nosotros hemos empleado permite ver más claramente el signifi- 
cado, pero existen numerosas alternativas... incluyendo la de comprimirlo to- 
do en una o en dos líneas. 

Un segundo ejemplo, más sencillo, nos muestra un if sin else. En BASIC, 
es así: 


100 IF P = 0 THEN 120 
110 LETQ =1 
120 


mientras que su equivalente en PASCAL es 


if p< >0 then 
q:=1; 


En muchos BASIC se puede escribir algo muy similar a la precedente sen- 
tencia PASCAL. (En realidad, muchos BASIC ofrecen en su integridad el 
IF ... THEN... ELSE del PASCAL.) 


La esencia del if en PASCAL consiste en pensar en forma positiva. En otras 
palabras, pensar en lo que quieres que se haga cuando la relación es verdadera 
(true); en el BASIC mínimo, por el contrario, frecuentemente se piensa en tér- 
minos de lo que se salta, es decir, de lo que no se hace, si una relación es ver- 
dadera. 


Saltos hacia atrás 


En BASIC es frecuente que el número de línea que sigue a un THEN espe- 
cifique un salto hacia atrás más bien que hacia adelante; estas sentencias IF 
no se pueden traducir al PASCAL en la forma arriba mostrada. Al parecer, 
necesitan un GOTO. 

Esto nos lleva a un punto importante: los GOTO son *“*malos”” de la pro- 
gramación. Y son tanto más insidiosos precisamente porque su aspecto es tan 
simple e inofensivo. Por lo menos, eso es lo que dice el profesor Primple. Los 
académicos revelaron la perversidad del GOTO en los años sesenta, y en nues- 
tros días nunca se nombra a este ““malo”” en los centros de la ciencia y la erudi- 
ción. En los años setenta hubo otros que siguieron la tendencia marcada por 
los académicos, y los duros hombres de negocios se convencieron de que el 
GOTO les estaba haciendo perder dinero, por lo cual se le debía despedir. 

Cuando escribas en PASCAL, debes desterrar a los GOTO de tu mente. 
Un GOTO hacia atrás representa parte de un bucle, y se debe expresar utili- 
zando las construcciones para bucles que presentaremos pronto. Un GOTO 
hacia adelante se puede expresar normalmente con sentencias if. 

Si tomas un programa BASIC ya existente y lo traduces al PASCAL, verás 
que te resulta difícil eliminar los GOTO. Sólo podrás hacerlo si repites tus al- 
goritmos en términos de construcciones de un nivel más elevado. Si has usado 
los GOTO durante años, la acomodación te será difícil, pero inténtalo de to- 
dos modos. Pronto te darás cuenta de que el pasarse sin GOTO es razonable- 
mente indoloro. Tal vez una analogía apropiada sea el cambio desde escribir 
a máquina con un solo dedo, que tiene que andar saltando por todo el teclado, 
a mecanografiar correctamente con un método unificado, utilizando los diez 
útiles o facilidades que te proporcionan tus manos. 

La ventaja que tiene la eliminación de los GOTO es que los programas se 
hacen más legibles. También se hace más facil el trabajo de verificar que los 
programas no contengan errores lógicos. 


Sentencias GOTO 


“Espera un momento”, dijo Bill, con una sonrisa triunfante. Sor- 
prendentemente, sacó un libro de PASCAL que estaba oculto tras una 
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obra maestra titulada Programas de guerras entre Galaxias. “Veo que 
en PASCAL se pueden escribir GOTO. En realidad son igual que en BA- 
SIC, sólo que, como de costumbre, hay un montón de morralla redun- 
dante que especificar. Se puede escribir 


goto 10; 
y a continuación se puede escribir 
10: 


delante de la sentencia a la que se quiere ir con el GOTO. Se pueden uti- 
lizar los números de etiqueta que se quiera, sin que sea necesario que 
estén en ningún tipo de orden. La única molestia es que al principio mis- 
mo del programa —después de esa línea inútil de program— hay que 
escribir una línea de la forma 


label 10, 20, 40, 67, ...; 
relacionando todas las etiquetas que se hayan usado.” 


A decir verdad, el goto es útil de vez en cuando en el PASCAL, aun cuan- 
do el profesor Primple lo niegue. En realidad, los compiladores de PASCAL 
suelen estar escritos en PASCAL también, y algunos de ellos usan goto. El 
goto es especialmente útil en situaciones de error, en las que la acción natural 
es salirse de un salto del curso lógico actual y pasar a alguna acción completa- 
mente separada. Sin embargo, nosotros nos atenemos a nuestro consejo: lo 
mejor es tratar de desterrar los goto de nuestra forma de pensar, e introducir- 
los sólo como último recurso. 


Sentencias FOR 
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Ya en el capítulo 1 vimos ejemplos sencillos del for en el PASCAL. En BA- 
SIC, la variable controlada, es decir, la variable cuyo nombre sigue al FOR, 
ha de ser del tipo de datos numérico. En el PASCAL, como veremos, puede 
ser de otros tipos de datos, pero sí es numérico tiene dos severas restricciones. 
(““Querrás decir demasiado severas restricciones”,”” dijo Bill.) (N. del T.: Otro 
juego de palabras, entre las homófonas two, dos, y too, demasiado.) 

La primera restricción, que ya mencionamos anteriormente, es que la va- 
riable controlada no ha de ser real. La razón de esta restricción es que la arit- 
mética real es inexacta. Una sentencia de BASIC tal como 


FOR K = .1 TO 1 STEP .1l 


es, por consiguiente, jugar con fuego. Si al sumar diez repeticiones de .1 se 
obtiene 1.0000001 en lugar de 1, entonces el bucle se ejecuta nueve veces, y 
no diez como se deseaba. 

La segunda restricción procede de una de las facetas de la brevedad del PAS- 
CAL: no existe en él el equivalente del STEP del BASIC. El paso ha de ser 
1 ó —1. En este último caso, se escribe downto en vez de to por ejemplo: 


for k:=1 to 10 do 

for k:=10 downto 1 do 

for índice: =i+1 to abs(q)do 

for índice: = último downtoprimerodo 


En los dos ejemplos últimos, al comienzo del bucle se toman los valores 
de i, q, último y primero, y ningún cambio que puedan experimentar estos 
valores dentro del bucle tendrá efecto alguno sobre el for. El BASIC tiene una 
regla similar. No se debe cambiar dentro del bucle el valor de la variable con- 
trolada, ni se debe suponer que después de que 


for k:=1 to 10 do (x ... *); 


haya terminado, k va a tener necesariamente el valor 11. 

No te desanimes por estas restricciones, ya que están sobradamente com- 
pensadas por otras dos sentencias de bucle que provee el PASCAL. La prime- 
ra es la sentencia while. Tiene una sintaxis similar a la de una sentencia if sin 
else; la diferencia es que un if hace que una sentencia se ejecute una vez si una 
condición es verdadera, mientras que un while hace que una sentencia se repi- 
ta continuamente mientras la condición siga siendo verdadera. El ejemplo que 
sigue lo ilustra. 


cuenta: =1; 
(x 
.) 
if cuenta<11 then 
begin 
writeln(cuenta); 
cuenta: = cuenta + 2; 
end; 
while cuenta< 11 do 
begin 
writeln(cuenta); 
cuenta: = cuenta + 2; 
end; 


El if imprime el valor 1 e iguala cuenta a 3. El bucle while se ejecuta cuatro 
veces. La variable cuenta empieza en 3, como resultado del if precedente, y 
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se incrementa en 2 cada vez que se repite el bucle. Cuando cuenta llega a 11, 
la condición del while se hace falsa, y el bucle se interrumpe. Así los valores 
que se imprimen en el buche son 3, 5, 7 y 9. El while que acabamos de ver 
nos enseña también la forma en que se puede programar el equivalente de un 
for con un paso de 2. 

La segunda construcción adicional de bucle es el repeat. El ejemplo que 
sigue muestra su sintaxis: 


cuenta:= 3; 
(x 
. k) 
repeat 
writeln(cuenta); 


-cuenta: = cuenta + 2; 
until cuenta> = 11; 


El significado de lo anterior es obvio. El bucle repeat es semejante a un 
bucle while, con la salvedad de que la comprobación viene después del bucle, 
en vez de antes. En realidad, este ejemplo de repeat es otra forma de expresar 
nuestro anterior ejemplo de while. Obsérvese la sutileza de la sintaxis del PAS- 
CAL, que nos permite acortar el programa al no exigirnos que pongamos un 
begin y un end encerrando el cuerpo del bucle repeat, aun cuando el mismo 
implique más de una sentencia. Si piensas que esta regla te puede confundir, 
pon siempre el begin y el end, pues no tendrán ningún efecto perjudicial. 

Todas las construcciones de bucle del PASCAL se pueden anidar, exacta- 
mente lo mismo que las sentencias FOR en BASIC. 

Si tu forma de pensar está controlada por el BASIC, tu mente simulará 
un bucle con la adopción de una secuencia de valores para una variable, como 
en una sentencia FOR. Si haces el cambio al PASCAL, has de ensanchar tu 
mente y pensar ““bucle”” donde antes pensabas “GOTO hacia atrás””. Tales 
bucles se escriben naturalmente usando while y repeat. Indudablemente, para 
empezar probarás primero con un while y luego lo cambiarás a un repeat o 
viceversa. Cuando hayas repetido este procedimiento durante algún tiempo, 
llegarás a saber instintivamente cuál de las dos construcciones utilizar en cada 
caso; la diferencia clave es que un bucle repeat se ejecuta siempre por lo menos 
una vez, mientras que con el while no siempre ocurre así. Para ponerlo de ma- 
nifiesto, considera lo que ocurrirá en nuestros ejemplos anteriores si el conta- 
dor (count) empieza con el valor 100, en vez del 3; el bucle while no imprime 
nada, pero el repeat imprime 100. 

Para resumir, si estamos acostumbrados a trabajar con una sola herramienta 
y nos regalan un juego de tres para sustituirla, necesitaremos algún tiempo pa- 
ra adaptarnos. Si consideramos que los bucles constituyen frecuentemente la 
característica más importante de un programa, y que las tres herramientas del 
PASCAL son mucho mejores que la única del BASIC, veremos que vale la 
pena hacer un esfuerzo para adaptarse adecuadamente. 


Sonidos y gráficos 


Tras haber estudiado detenidamente la formación de bucles, llegamos aho- 
ra a un tema que se puede despachar con brevedad. 

Hay muchos BASIC que disponen de medios para dibujar gráficos y pro- 
ducir sonidos. Tales medios faltan totalmente en el PASCAL, y apenas empie- 
zan a introducirse en algunas de sus ampliaciones. Lo mismo ocurre con el 
PEEK y el POKE. 


“Hay una regla muy sencilla acerca del PASCAL”, dijo Bill. ““Si al- 
go es divertido, no se puede hacer.”” 

“Me pregunto cómo será el superventas de los programas porno en 
PASCAL, sin ningún gráfico”, añadió con una sonrisa afectada. 


Las sentencias ON 


La sentencia ON del BASIC 


100. ON X GOTO 110, 150, 200 
110 REM CASO EN QUE X = 1 
120 LET Y = 3 

130 GOTO 500 


150 REM CASO EN QUE X = 2 
160 PRINT Y 

170 LET Y =7 

180 GOTO 500 


200 REM CASO EN QUE X = 3 
210 LET Y = 29 


500 


se traduce en el PASCAL en una sentencia case de la forma 


case x of 
l: 
y:= 3; 
Ze 
begin 
writeln(y); 
y:= 7; 
end; 
3: 


y:= 29; (x* hablando estrictamente, este punto y coma se debe omitir +) 
end; 
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Los números 1, 2 y 3 no son etiquetas ordinarias. Bill no puede ir a ellas 
con GOTO. Se las conoce como case labels (etiquetas de la sentencia case), 
y son constantes del mismo tipo que x, es decir, en nuestro caso, integer O 
enteros. 

La sentencia case es muchísimo mejor que la ON del BASIC. Pueden utili- 
zarse como etiquetas de la sentencia case todos los valores posibles de x, y pa- 
ra un sólo case se puede poner una lista de etiquetas, separadas por comas, 
por ejemplo: 


23, 19, 46:y:= 9; (+ etiquetas múltipes de case x) 


Las etiquetas de case pueden estar en cualquier orden; desde luego, no se 
puede emplear la misma etiqueta de case más de una vez dentro de la misma 
sentencia case. 

Esto es una gran ayuda para la Sra. Buzz. El conjunto de la estructura, 
con los diferentes casos (cases) pulcramente separados, contribuye a mejorar 
la legibilidad de los programas. 

El case selector o selector de casos (en nuestro ejemplo, x) puede ser cual- 
quier expresión; puede producir un valor entero o, como veremos más adelan- 
te, valores de otros tipos, como carácter o howout. (En estas situaciones, las 
etiquetas de case no serían números. Para howout, por ejemplo, serían stum- 
ped, bowled, etc.) Esto contribuye en gran medida a la flexibilidad de las sen- 
tencias case. 

El único problema en relación con las sentencas case es en el caso de pro- 
ducirse algún error. ¿Qué ocurriría en nuestro ejemplo si x tuviera el valor 4 
y no hubiera ninguna etiqueta de case 4? Desafortunadamente, el PASCAL 
no define lo que ocurre en tal situación; un buen compilador producirá un men- 
saje de error, pero uno malo podría realizar cualquier acción imprevisible. 


Sentencias BASIC sin equivalencias en PASCAL 


Hay cierto número de sentencias BASIC que no tienen equivalencia en 
PASCAL. 

La sentencia END no tiene equivalente, si se exceptúa tal vez el punto al 
final mismo de un programa PASCAL. 

Un programa PASCAL se para automáticamente cuando llega al final. La 
mayoría de las realizaciones o implementaciones del PASCAL ofrecen una sen- 
tencia ; 


halt; 


que es equivalente al STOP del BASIC, pero no es completamente estándar. 


De un modo análogo, ni la sentencia RANDOMIZE ni la función incorpo- 
rada RND figuran en el informe del PASCAL, pero muchas implementacio- 
nes del lenguaje ofrecen facilidades similares. 

Las sentencias DATA, READ y RESTORE no tienen equivalentes en PAS- 
CAL. Todas las entradas o introducciones de datos se han de hacer en una 
forma semejante al empleo de la sentencia INPUT del BASIC. DATA es muy 
útil en BASIC para inicializar tablas. El proceso para hacer lo mismo en PAS- 
CAL es mucho más pesado, hay que escribir sentencias explícitas de asigna- 
ción, o bien introducir los valores desde un archivo. 

La odiosa sentencia OPTIONBASE del BASIC está subyacente en el equi- 
valente PASCAL de la DIM del BASIC. 


Constantes, tipos y declaraciones 


Finalmente, es útil presentar en este momento una facilidad del PASCAL 
que ya se anunció en el capítulo 2: la posibilidad de hacer fáciles los cambios 
en las constantes. Esto se hace en PASCAL dando un identificador a la cons- 
tante como nombre, y haciéndole igual al valor de la constante. Todas estas 
constantes se agrupan en una sección const que viene al principio mismo de 
las declaraciones (**pero detrás de las etiquetas””, dijo Bill), de modo que se 
localicen fácilmente si es preciso modificarlas. A continuación aparecen algu- 
nos ejemplos de declaraciones de constantes: 


const 
anchodelínea = 72; 
máximoderepeticiones = 20; 
3% 


carácterdeasentimiento = “s”; 
(x* las constantes pueden ser caracteres aislados «) 


Luego, estos nombres se pueden usar en cualquier lugar del programa en 
el que se hubiera empleado la constante. 

Del mismo modo que se dan nombres a las constantes, también se les pue- 
den dar a los tipos. Puesto que es sensato dar un nombre a cada tipo, nosotros 
lo hemos hecho con todos los que introdujimos al principio de este capítulo, 
tales como howout o enteropequeño. (Más adelante presentaremos otros muchos 
tipos, tales como arrays o matrices y registros; también a todos éstos se les 
pueden asignar nombres.) Los nombres definidos por nosotros los usuarios se 
pueden utilizar en una forma semejante a la de los nombres incorporados en 
el PASCAL, como integer y real. En realidad, no hay necesidad de asignar 
nombres a los tipos, sino que se pueden escribir en forma explícita después 
de una declaración de variable. Así, 
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type 

dígito = 0..9; 
var 

minúmero: dígito; 


se puede escribir 


var 
minúmero: 0..9; 


No obstante, seguiremos ateniéndonos a nuestro consejo de asignar nom- 
bre a los tipos, aunque no comprendas la razón para ello hasta más adelante 
en este libro. (En algunas ocasiones, no seguiremos nuestro propio consejo; 
la excusa para ello será la de hacer los ejemplos autocontenidos o autónomos, 
y no dependientes de una declaración de type separada.) 

Hasta ahora hemos mencionado cuatro posibles secciones de declaracio- 
nes. En el ejemplo que sigue se resumen (dando una declaración en cada sec- 
ción) y se muestra la forma en que deben ordenarse. 


label 
200; 
const 
anchodelínea = 40; 
type 
posicióndelínea= 1..anchodelínea; 
var 
punterodelínea: posicióndelínea; 
(* Ahora vienen las declaraciones de procedimientos y de funciones, véase 
el capítulo próximo x) 
begin 
(x* Aquí empiezan las sentencias ejecutables x) 


Cualquier sección que no se emplee, puede omitirse. Es fácil recordar el 
orden. Las etiquetas o labels vienen en primer lugar, de modo que Primple 
pueda ver inmediatamente si usas goto, y, si lo haces, ya no tendrá que mirar 
nada de lo que hayas escrito. En cuanto al resto, las const podrían ser necesa- 
rias para los type, y éstos serán necesarios con toda seguridad para las var, 
como muestra nuestro ejemplo; y esto fija el orden. 
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Facilitan la ida y el regreso. 


Anuncio de billetes ferroviarios 
de ida y vuelta 


Subrutinas 
y funciones 


Conceptos básicos 


Una de las mejores formas de dividir un programa grande en unidades ma- 
nejables es por medio de subrutinas. La sencilla facilidad del GOSUB y el RE- 
TURN que proporciona el BASIC mínimo es tolerable para programas peque- 
ños, pero se hace completamente inadecuada cuando se trata de programas 
grandes. (Esa es la razón por la que varios BASIC ofrecen facilidades más am- 
plias.) 

El PASCAL soporta tanto funciones como subrutinas; estas últimas reci- 
ben el nombre de procedures, o procedimientos. Las funciones del PASCAL 
tienen algún parecido con las del BASIC, especialmente con las funciones mul- 
tilínea que ofrecen algunos BASIC. Un procedimiento PASCAL es muy pare- 
cido a una función PASCAL; puede pensarse en él como en una función que 
no produce ningún resultado. Por consiguiente, se parece mucho más a una 
función multilínea de BASIC que al mecanismo del GOSUB y el RETURN. 

Empezaremos dando un ejemplo de una función multilínea BASIC que halla 
el máximo común divisor de dos enteros, X e Y. Esta función se ha tomado, 
con autorización de John Wiley and Sons, del excelente libro sobre BASIC es- 
crito por Kemeny «€ Kurtz (1980). 
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110 DEF FNE (X, Y) 

120 REM ESTA FUNCION HACE USO DE UN ALGORITMO 
DEBIDO A EUCLIDES 

130 LET Q = INT(X/Y) 

140 LET R = X—Q*Y 

150 IF R = 0 THEN 190 


160 LETX = Y 
170 LET Y = R 
180 GO TO 130 
190 LET FNE = Y 
200 FNEND 


La función PASCAL equivalente es como sigue: 


function MáximoComúnDivisor(númerol: enteropositivo; 
número2: enteropositivo): enteropositivo; 
(x* Esta función produce el máximo común divisor del númerol y el 
número2. El método usado es el algoritmo de Euclides. +) 
var 
resto: integer; 
begin 
repeat 
resto: = númerol mod número2; 
if resto< >0 then 
begin 
númerol:= número2; 
número2:= resto; 
end 
until resto= 0; 
MáximoComúnDivisor: = número2,; (+* resultado de la función +) 
end; (x* MáximoComúnDivisor x*) 


Lo que precede es una declaración de la función, y se coloca con las demás 


declaraciones. Específicamente, las declaraciones de funciones y de procedi- 
mientos se colocan después de las declaraciones de variables, es decir, después 
de la sección que lleva el encabezamiento var. 


La llamada a una función PASCAL se hace en una forma similar a la de 


una función BASIC, por ejemplo: 


x:= y + MáximoComúnDivisor(y + 6,q); 


Argumentos y parámetros 


Si escribimos en BASIC 


DEF FNX(P) = ... 


PRINT FNX(L + 9), ENX(Q9) 


a la variable P usada en la definición de FNX se le llama el parámetro, y a 
las expresiones tales como L + 9 y Q9 que se usan en las llamadas de FNX 
se les llama argumentos. El parámetro es una especie de elemento ficticio. Ca- 
da vez que se llama a la función, el valor del parámetro toma el valor del argu- 
mento correspondiente. 

El PASCAL funciona en una forma muy similar, con la salvedad de que 
la terminología que se utiliza es diferente: a los argumentos se les llama pará- 
metros reales, y alos parámetros se les denomina parámetros formales. Desde 
luego, cada uno es libre para llamar a las cosas como guste, y nos parece que 
será mejor, en este libro, conservar la sencilla terminología del BASIC. 

Aplicando esta terminología al MáximoComúnDivisor, los identificadores 
númerol y número2 son parámetros; y, en nuestro ejemplo de llamada, y + 6 y 
q son los argumentos correspondientes a númerol y número, respectiva- 
mente. 

Sólo por mantener la imparcialidad, haremos al PASCAL el favor de res- 
petar su convención, en virtud de la cual se llama a una subrutina un procedi- 
miento. 

En el PASCAL, a diferencia del BASIC, cada procedimiento o función pue- 
de tener tantos parámetros como uno quiera. Así, una función podría no tener 
ningún parámetro, y otra podría tener cinco. Si esto es así, nunca tendremos 
que suministrar ningún argumento cuando llamemos a la primera función, y 
siempre tendremos que suministrar cinco cuando llamemos a la segunda. Al 
hacer la llamada de la función, se asigna al parámetro el argumento, razón 
por la cual ambos han de ser compatibles en cuanto a tipo. Las reglas son exac- 
tamente iguales que las de una sentencia normal de asignación. Por tanto, un 
argumento entero (integer) puede servir para un parámetro real, pero no a la 
inversa. A las funciones incorporadas les son aplicables unas reglas idénticas; 
así, por ejemplo, aunque sqrt pide un argumento real, de hecho aceptará uno 
entero y lo convertirá a forma real entre bastidores. 


Puntos a observar 


Son muchos los puntos a observar en relación con la función MáximoCo- 
múnDivisor. El primero es que la función parece enteramente un programa 
PASCAL completo (si exceptuamos el uso de “*;”” en vez del **.”” después del 
end final). Esta característica de diseño es deliberada y muy afortunada, ya 
que las funciones y los procedimientos constituyen un medio para dividir o des- 
componer un programa en subprogramas más pequeños. Es conveniente con- 
siderar a un programa como un procedimiento; una ejecución (run) del pro- 
grama es equivalente a una llamada a este procedimiento. El programa tiene 
como parámetros los archivos que se usan para comunicar con el mundo exte- 
rior. Esa es la razón por la que la primera línea de un programa es 


program nombreprogramalinput, output); 


Los nombres input y output son nombres internos del PASCAL para los 
archivos de entrada y salida por omisión (default). Estudiaremos más esta cues- 
tión en el capítulo 9. La parte ejecutable de la función va encerrada entre un 
begin y un end. Esto se parece a una sentencia compuesta, pero seguiremos 
necesitando el begin y el end aun cuando la función esté formada por una sola 
sentencia. 

El segundo punto es que las declaraciones son locales para la función. Esta 
es una idea realmente importante, y más adelante en este capítulo le dedicamos 
mucha atención. 

El tercer punto se refiere a la finalidad de la línea de encabezamiento 


function MáximoComúnDivisor(númerol: enteropositivo; 
número?: enteropositivo): enteropositivo; 


Este encabezamiento, que hemos repartido en dos líneas porque es bastan- 
te largo, da primero el nombre de la función. No tenéis obligación de usar nom- 
bres tan largos como MáximoComúnDivisor, pero los nombres largos, hasta 
cierto punto, ayudan a la legibilidad. El nombre de la función va seguido por 
las declaraciones de sus parámetros, encerradas entre paréntesis. Estas decla- 
raciones se escriben exactamente en la misma forma que la lista de declaracio- 
nes que se escribe en la sección var; obsérvese que no se pone punto y coma 
después de la última declaración. Nuestros dos parámetros, númerol y número?, 
son ambos del tipo enteropositivo, el tipo de subrango que definimos en el ca- 
pítulo anterior. En realidad, podíamos haber acortado estas declaraciones de- 
jándolas en 


(númerol, número2: enteropositivo) 


El elemento final de encabezamiento da el tipo de datos del resultado de 
la función. (Por una caprichosa casualidad, en este ejemplo el enteropositivo 


se produce tres veces seguidas; en general, como veremos, pueden ser tres ti- 
pos diferentes.) Por tanto, la forma general del encabezamiento de una fun- 
ción es 


function <nombre>(< lista de parámetros > ): <tipo>; 


En las funciones que no tienen ningún parámetro, se omite la lista de pará- 
metros indicada entre paréntesis. 

Todos los tipos de datos usados en las declaraciones de funciones han de 
ser nombres de tipos. No se puede, por ejemplo, escribir un 1..10 explícito. 
Esta era una de las razones por las que anteriormente te aconsejamos que asig- 
naras un nombre a todos los tipos que definas. 

La razón de que empleemos como tipo de datos de los dos parámetros en- 
teropositivo mejor que integer, es para ayudar a Perkins. Si se llama a la fun- 
ción con un argumento negativo o cero, Perkins puede señalar inmediatamen- 
te la equivocación cometida. (En realidad, si hubiéramos permitido usar cual- 
quier entero [integer] como argumento, la función sólo fallaría cuando el se- 
gundo argumento fuera cero... y ello, porque mod intentaría dividir por cero. 
La función daría un resultado si cualquiera de los dos argumentos fuese nega- 
tivo, aunque es dudoso que este resultado fuese el deseado por el usuario. Es 
como si un cliente pidiese en un restaurante rosbif y natillas; el resultado pue- 
de conseguirse, pero un camarero atento no aprobaría la elección de menú.) 

Las ventajas de usar también enteropositivo, en vez de integer, como tipo 
de datos del resultado de la función, no son tan patentes. Sin embargo, ello 
proporciona alguna información adicional, tanto a Perkins como a cualquier 
lector del programa. Y cuanto más sepa Perkins, más seguros estamos. 

Los dos ejemplos de declaraciones de funciones que siguen a continuación, 
deberán arrojar más luz sobre los encabezamientos de funciones. 


type 
AA 0..maxint; (« un entero posttivo o cero entero sx) 
var 
leecuenta: integer; («* cuenta de los números leídos por la función 
leecubo x) 
(or 


*) 

function potencia(X:real;K: poso0integer): real; 

(* Esta función produce la k-ésima potencia de x x) 
var 

resultado: real; 

índice: integer; 
begin 

resultado: = 1; 

for índice: =1 to k do 

resultado: = resultado x X; 
potencia: = resultado; 
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end; (* potencia x) 


function /eecubo: real; 
(x* Esta función lee un número real y lo eleva al cubo. También 
cuenta el número de números leídos x) 
var 
númeroleído: real; 
begin 
read(númeroleído); 
leecubo: = potencia(númeroleído, 3); 
leecuenta:= leecuenta + 1; (x* cuenta los números leídos x+) 
end; (x leecubo x) 


La función potencia muestra parámetros cuyos tipos son diferentes. 

La función /leecubo muestra una función sin ningún parámetro. Nos mues- 
tra también que una función puede llamar a otras funciones y puede hacer re- 
ferencia a una variable declarada fuera de sí misma (/eecuenta en el ejemplo 
precedente). Todos estos puntos tienen paralelos exactos en BASIC. 

Estas dos funciones ilustran también un buen hábito de programación: po- 
ner un comentario al comienzo de una función para explicar lo que ésta hace, 
y otro después del final de la función indicando el nombre de la misma. 


Cómo trabaja la función 


Si ahora examinamos la forma en que trabaja nuestra función original Má- 
ximoComúnDivisor, veremos que utiliza un repeat en lugar del GOTO hacia 
atrás del BASIC. El programa resultante de ello es más fácil de comprender. 
Sin embargo, es un poco menos eficiente en su ejecución, ya que la condición 
“resto =0” se verifica o comprueba dos veces. Este es un fenómeno común; 
algunos bucles tienen la forma 


Comienzo del bucle 
Acción 1 
Verificación de la condición terminadora y, si es verdadera (true), 
salida del bucle 
Acción 2 
Fin del bucle 


De estos bucles puede decirse que se ejecutan “N veces y media”, para al- 
gunos N. Algunas veces se les puede convertir cómodamente en bucles ordina- 
rios variando la redacción del algoritmo; de no ser así, sólo se pueden expresar 
en PASCAL introduciendo pequeñas ineficiencias como la precedente, u, ose- 
mos decirlo, mediante el uso de un goto. Las ineficiencias son un precio que 


la mayor parte de la gente está dispuesta a pagar. Algunos lenguajes tienen 
una sentencia especial que dice ““salida del bucle actual””; esto resuelve el pro- 
blema. 

Finalmente, observamos que en nuestra versión PASCAL no hace falta la 
función BASIC INT, ya que de todos modos estamos trabajando con enteros 
o integers. Puede argumentarse incluso que el trabajar con números reales, como 
lo hace el BASIC, es una forma antinatural de resolver este problema. 

Toda llamada a una función f ha de ejecutar como mínimo una sentencia 
de asignación de la forma 


f:= <expresión >; 


Obsérvese que el uso del nombre de una función, f, en el término izquierdo 
de una asignación es bastante especial; cualquier otro uso de f supondría una 
llamada a f. La última asignación de este tipo a f define el resultado que se 
ha de entregar. Tal es la finalidad de la última línea de MáximoComúnDivisor, 
que es 


MáximoComúnDivisor: = número?2; 
En PASCAL no existe la sentencia RETURN. La función o el procedimiento 
vuelven automáticamente al programa principal tan pronto como llegan a su 


end, del mismo modo que el programa principal se termina automáticamente 
cuando llega a su propio end. 


Procedimientos 


Un procedimiento se declara exactamente en la misma forma que una fun- 
ción, con la salvedad de que la línea de encabezamiento se escribe así: 


procedure < nombre > (< lista de parámetros > ); 
Al igual que ocurre en las funciones, la lista de parámetros entre paréntesis 
se omite si no existe ningún parámetro. A continuación tenemos un procedi- 


miento para imprimir los números 1 a n, cada uno en una línea: 


procedure papelmojado(n: integer) 
(* imprime los números 1 a n x) 


var 
índice: integer; 

begin 
for índice: = 1 to n do 


writeln(índice); 
end; (x* papelmojado +) 


La llamada a un procedimiento se escribe como una llamada de función, 
con la salvedad de que una llamada de procedimiento es una sentencia por sí 
misma, por ejemplo: 


papelmojado(6); 
if x > 0 then 
papelmojado(q + 3); 


Dado que los procedimientos son similares a las funciones, gran parte de 
lo que digamos acerca de unos será también de aplicación a los otros. Por con- 
siguiente, durante el resto de este capítulo emplearemos el término genérico 
rutina para hablar de un procedimiento o una función, indistintamente. Es un 
término tomado del lenguaje BCPL. 


Procedimientos incorporados 


En el capítulo precedente presentamos algunas de las funciones incorpora- 
das en el PASCAL. Además, el PASCAL tiene cierto número de procedimien- 
tos incorporados. Muchos de ellos tienen relación con las entradas/salidas, y, 
efectivamente, el writeln que ya hemos utilizado en varios ejemplos es uno de 
ellos. A medida que progresemos en la lectura de este libro, encontraremos 
otros varios procedimientos (y funciones) incorporados. En el Apéndice A se 
da un sumario de todos ellos. 

Algunas de las rutinas incorporadas del PASCAL ilustran una flagrante 
injusticia. Los programadores de sistemas que definen las rutinas incorpora- 
das disponen de medios o facilidades que a nosotros, los usuarios comunes, 
nos están prohibidos. En particular, las rutinas incorporadas tienen argumen- 
tos que se omiten opcionalmente, y, como ponen de manifiesto los procedi- 
mientos de entrada/salida, pueden tener unas listas arbitrariamente largas de 
argumentos de cualquier tipo. Podemos explotar estas facilidades cuando lla- 
mamos a rutinas incorporadas, pero no podemos usarlas cuando definimos 
nuestras propias rutinas. 


Declaraciones locales 


Una rutina puede tener declaraciones que sean locales, o exclusivas de la 
misma. Entre el encabezamiento de la rutina y su begin, podemos definir un 
conjunto o juego de declaraciones de label, const, type, var y, desde luego, 
declaraciones de rutinas anidadas. En la función MáximoComúnDivisor he- 


mos sido modestos en cuanto a nuestras declaraciones locales. Existe simple- 
mente una sola variable, llamada resto. Además, los parámetros númerol y 
número? están tratados como declaraciones locales, de modo que tenemos un 
total de tres variables locales. Estas declaraciones locales son una de las carac- 
terísticas más importantes del PASCAL. Significan que las rutinas pueden ser 
autónomas, o autocontenidas. Ello tiene tres grandes ventajas: 


1) No hay necesidad de elegir nombres singulares y únicos para las variables 
locales usadas en una rutina. Si cualquiera de los nombres que usemos es- 
tá utilizado ya fuera de la rutina, nuestra utilización local del mismo tiene 
precedencia sobre su utilización exterior. (En el BASIC hay un atisbo de 
esto cuando se emplea una declaración como 


DEF FNA(X) = 3 — X/Y 


Aquí el nombre X es local para la declaración de la función FNA.) El uso 
local puede ser completamente diferente del uso externo; el primero, por 
ejemplo, podría ser un type y el último un var. 


2) La Sra. Buzz puede poner a cada obrera a escribir una rutina diferente, 
sin que unas interfieran a las otras. 


3) Las rutinas son más fáciles de depurar y de mantener, porque se reducen 
los efectos del exterior. Un principio muy sano en el diseño de programas 
es la idea de la reserva u ocultación de información, debida a Parnas (1972). 
El aforismo de Parnas es que los detalles de la forma en que representa- 
mos y manipulamos cada juego o conjunto de objetos deben estar confi- 
nados a unas pocas rutinas; esta información detallada queda oculta para 
el resto del programa, el cual trata a estas rutinas como “cajas negras”. 


Refinamiento progresivo 


Hemos dicho que las rutinas pueden contener en sí mismas las declaracio- 
nes de sus propias rutinas locales. Esto contribuye a la estructuración de los 
programas y, en particular, al método de estructuración conocido como refi- 
namiento progresivo (stepwise refinement), que fue introducido por el mismo 
Wirth (1971). En este método se proponen primero unas rutinas muy poten- 
tes, y se resuelve el problema utilizándolas. A continuación se toma cada una 
de estas potentes rutinas y se la codifica utilizando rutinas más pequeñas. Este 
proceso se prosigue hasta llegar a rutinas sencillas que se puedan codificar di- 
rectamente. Un ideal adoptado por muchos programadores es que el progra- 
ma principal y el cuerpo de cada rutina no excedan de una página de texto, 
digamos unas cincuenta líneas. El resultado de ello es que el programa, por 
grande que sea, será relativamente fácil de leer. No te preocupes, por tanto, 
si defines una rutina a la que luego se llama una sola vez; si esta rutina hace 
que tu programa sea más legible, se ha ganado el derecho a la permanencia. 
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El ámbito local 


En PASCAL, todas las declaraciones tienen su ámbito. El ámbito de una 
declaración es la rutina en la cual se produce, junto con todas las rutinas que 
sean locales de la primera, y cualesquiera otras que estén anidadas aún más 
profundamente en el interior de estas rutinas locales, y así sucesivamente. (Las 
declaraciones hechas en el programa principal tienen como ámbito propio el 
de todo el programa, llamándose “de ámbito global””.) Fuera de su propio ám- 
bito, una declaración es desconocida, y es posible usar el mismo nombre para 
significar algo completamente diferente. En esto existen dos casos posibles: pue- 
de reutilizarse un nombre en ámbitos disjuntos y no solapados, o bien se pue- 
de reutilizar en un ámbito incluido en el de una declaración anterior. En este 
último caso, como hemos dicho, la declaración más interna toma precedencia 
sobre la(s) más externa(s), dejándola(s) en suspenso. Estos principios se ilus- 
tran en el ejemplo que sigue. Los comentarios incluidos en el programa expli- 
can las reglas relativas a los ámbitos; para hacer más fácil la lectura, los nom- 
bres se han encerrado en un cerco en el sitio en que se declaran. 


program usa(input, output); 
(x* Los nombres declarados en el programa principal son todos de esta- 
dos de los EE.UU. x) 


var 
Qermont): integer; 
Qhio). real; 


(* SZLEEEEEEEEEEEES<EEEE<<E<<<<<C< 2) 


procedure Gregom((rcoln): integer; Cugeno): real); 


(x* Las variables locales son nombres de pueblos y ciudades de Oregon x) 


const 

Cend= 36; 
type 

CewporD= (Gstoria ) Uban»)); 
var 


Gale): newport; 
fostery 1..bend, (x* un pueblo muy pequeño x) 
(x SEEEEEEEEEEEE<E<<<<<<<<<<<< 1) 


procedure (Portland (Ffremondy: newport); 


(* Las variables locales son nombres de calles de Portland x) 
var 


lombard>: integer; 
Gnion): real; 
Qermond) 1..123; (+ no tiene relación alguna con el vermont anterior x) 


: 1.. bend, (+ no tiene relación alguna con el foster anterior x) 


begin 

(* Aquí todas las declaraciones anteriores están dentro del ámbito, ex- 
cepto las de vermont y foster externas, que han quedado en suspenso 
al tomar precedencia las locales del mismo nombre +) 


(E 


. *) 
end; (x portland +) 
(* Esto pone fin al ámbito de fremont, lombard, union, y los vermont 
y foster internos <) 
(* Los vermont y foster anteriores ya no están en suspenso, y entran de 
nuevo en el ámbito +) 
(* >>> >>>>>>>>>>>>>>>>>>>>>>>x) 


begin (* cuerpo de oregon +) 


(x 


*) 
end; (x* oregon +) 
(* Esto pone fin al ámbito de lincoln, eugene, bend, astoria, albany, 
newport, salem, foster, portland «x) 

(xx >>>>>>>>>>>>>>>>>>>>>>>>>>x) 
(* SLEEEEEEEEEES<EES<<<<<<<<<<<< xx) 
- procedure Graind ((incoln): real ¡Qangon: integer); 

(x Las variables locales son nombres de pueblos y ciudades de Maine x) 
(x El lincoln arriba escrito no tiene relación ninguna con el anterior x) 


var 


(portland): 1..6; (« no tiene ninguna relación con el portland anterior x) 
Qugustg): real; 
begin 


(x Aquí las declaraciones que se encuentran dentro del ámbito son ver- 
mont, ohio, oregon, maine, lincoln, bangor, portland, augusta x) 


(xr 
*) 


end; (* maine x) 
(* Esto pone fin al ámbito de lincoln, bangor, portland, augusta x) 
(* >>>>>>>>>>>>>>>>>>>>>>>>>>x) 
begin (* cuerpo del programa principal x) 
(* Aquí las declaraciones dentro del ámbito son vermont, ohio, 
oregon, maine x) 


(x 
*) 


end. 


Obsérvese especialmente el efecto que las reglas relativas al ámbito tienen 
sobre los nombres de las rutinas. Sólo se puede llamar a una rutina cuando 
su nombre esté dentro del ámbito. El nombre está dentro del ámbito durante 
toda la rutina o todo el programa en los cuales haya sido declarado. Así, se 
puede llamar a oregon y maine durante todo el programa, pero al procedimiento 
portland sólo se le puede llamar desde dentro de oregon. Y hay algo que aña- 
dir a esto: sólo se puede hacer referencia a un nombre después de haberle 
declarado; por consiguiente, no se puede llamar a maine en el interior de ore- 
gon. Si tenemos montones de rutinas que se llamen unas a otras, ello puede 
suscitar problemas de ordenación; de ellos hablaremos más adelante. 


Espacio de memoria para las variables 


En conexión con el ámbito local, hay un mecanismo relacionado con él, 
el cual se llama tiempo o duración de vida local (local lifetime). Si una variable 
es local de una rutina R, el PASCAL sólo asigna espacio de memoria para di- 
cha variable cuando se llama a R; al producirse el retorno de esta llamada a 
R, el PASCAL libera el espacio de memoria, y la variable deja de existir. Mien- 
tras R se encuentre activa, podría llamar a otras rutinas, haciendo así que otras 
variables vengan y se vayan, pero esto no tiene efecto alguno sobre las varia- 
bles locales de R. Si se llama a R una segunda vez, el proceso se repite; se asig- 
na de nuevo espacio de memoria para sus variables y, al producirse el retorno 
desde R, dicho espacio se libera de nuevo. Obsérvese que la variable muere 
cuando se libera su espacio de memoria. Si la variable renace más tarde como 
resultado de otra llamada, tiene un valor indefinido. (El PASCAL no tiene, 
como ciertos BASIC no estándar, un sistema para inicializar todas las varia- 
bles a cero.) 

Refiriendo estas reglas al programa de nuestro ejemplo, inicialmente se asig- 
na espacio de memoria a las variables vermont y ohio declaradas en el progra- 
ma principal. Estas permanecen en existencia durante toda la ejecución del pro- 
grama, siendo por tanto como las variables del BASIC. Supongamos que el 
programa principal llama a maine. En el mismo momento, nacen las variables 
lincoln, bangor, portland y augusta. (Las dos primeras son parámetros, y las 
otras dos son variables locales, pero todas estas cuatrillizas nacen al mismo 
tiempo.) Si posteriormente maine llama a oregon, nacen entonces lincoln (que 
no tiene ninguna relación con el lincoln anterior), eugene, salem y foster. Si, 
a su vez, oregon llama a su propio procedimiento local portland, nacerán en- 
tonces fremont, lombard, union, y nuevas encarnaciones de vermont y foster. 
Las variables que existen en este punto son las siguientes: 


*vermont 


: ertenecien l programa principal 
óle pertenecientes al programa principa 


*lincoln 
*bangor 
*portland 
*augusta 


pertenecientes a maine 


lincoln 

eugene 

salem 
*foster 


pertenecientes a oregon 


Fremont 

lombard 

union pertenecientes a portland 
vermont 

foster 


Las variables marcadas con un asterisco se hallan en suspenso, o en hiberna-- 
ción. No se puede hacer referencia a ellas porque no se hallan actualmente 
dentro del ámbito. (Recuérdese que las variables pueden estar fuera del ámbito 
por dos razones diferentes: pueden estar en suspenso por precedencia de otra 
local, como vermont y foster, o pueden pertenecer a un procedimiento separa- 
do y no solapado, como las variables de maine). Cuando las variables en sus- 
penso o hibernación entran de nuevo en el ámbito, como resultado del retorno 
de una rutina, vuelven a la vida sin haber sido afectadas por su sueño. 

Las variables que se hallen dentro del ámbito en cualquier momento están 
determinadas únicamente por la disposición del programa. Por otra parte, las 
variables que se hallen activas están determinadas por el comportamiento di- 
námico de aquél, y particularmente por las rutinas que estén activas cuando 
se llama a una rutina dada. (En nuestro ejemplo, resulta que las variables mai- 
ne están activas cuando se llama a oregon.) Sin embargo, se puede garantizar 
que todas las variables incluidas en el ámbito están activas..., si no fuera así, 
la programación sería una verdadera pesadilla. 

Siempre, tras los acontecimientos felices, vienen los funerales. Cuando se 
produce el retorno desde portland, sus cinco variables locales mueren. Las ver- 
mont y foster originales, que antes se hallaban en suspenso, salen de su hiber- 
nación. Cuando se produce el retorno de oregon, mueren sus cuatro variables, 
y las únicas que quedan para asistir al funeral son: 


vermont 4 e 
añito pertenecientes al programa principal 
lincoln 
bangor 
portland 


augusta 


pertenecientes a maine 


Todas éstas están dentro del ámbito. Si maine llama a oregon otra vez, re- 
nacen lincoln, eugene, salem y foster. (Es muy probable que ocupen los mis- 
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mos espacios de memoria que tuvieron anteriormente, pero esto no se puede 
garantizar, de modo que sus valores iniciales son indefinidos.) Al producirse 
el retorno desde oregon, las nuevas encarnaciones de estas variables mueren 
de nuevo. 

Finalmente, se producirá el retorno desde maine, matando a sus variables 
locales. Las únicas que podrán llevar luto por ellas serán las variables indes- 
tructibles vermont y ohio. 


Diferencias con respecto 
a la asignación permanente de memoria 


Si conservas una visión BASIC del mundo, es decir, si piensas que todas 
las variables excepto los parámetros han de tener espacio de memoria reserva- 
do permanentemente para ellas, es posible que tus programas en PASCAL fun- 
cionen aún, pero te perderás dos puntos importantes. Uno tiene que ver con 
la repetición, de la que hablaremos después, y el otro con las matrices o arrays 
grandes. Puede ocurrir que tengas algunas matrices grandes que sólo se necesi- 
ten durante un corto tiempo en la ejecución del programa. En tal caso, com- 
vierte cada matriz local en una rutina, y dispón tu programa de modo que lla- 
mes a esa rutina cuando necesites la matriz o array, y se retorne cuando hayas 
terminado con ella. (En algunos casos, se puede hacer a varias matrices locales 
de una rutina, pero aquí hemos supuesto el caso de una sola.) El espacio de 
almacenamiento para la matriz está reservado solamente durante el tiempo de 
vida de la rutina; todo el resto del tiempo, el espacio de memoria está libre, 
y se puede utilizar para matrices locales de otras rutinas. En esta forma, el ta- 
maño total de tus matrices puede ser mayor que la capacidad total de memoria 
que tengas; pero disponiéndolo todo en ámbitos que no se solapen, de modo 
que tus matrices no estén todas existentes al mismo tiempo, todavía podrás 
ejecutar tu programa. 

Un lenguaje que dispone de los mecanismos arriba mencionados para la 
creación de ámbitos locales, y de duraciones o vidas locales de las variables, 
recibe el nombre de lenguaje estructurado en bloques. Ya mencionamos este 
nombre anteriormente, sin definirlo; la mayoría de los lenguajes modernos y 
muy utilizados (aunque, ciertamente, no todos) son estructurados en bloques. 


La adaptación a la estructura en bloques 


Muchos programadores de BASIC no obtienen del PASCAL todos los be- 
neficios posibles, porque no están acostumbrados a pensar en términos de es- 
tructura de bloques. No caigas en esta trampa. Imita a la Sra. Buzz y haz el 


esfuerzo preciso para dividir tu programa en rutinas separadas, ninguna de- 
masiado larga, y asegurándote de que tus declaraciones estén tan localizadas 
como se pueda. Luego, cuando llegue el momento de hacer mantenimiento en 
tu programa, bendecirás al magnífico programador que lo escribió. 

Para elegir un ejemplo concreto de ámbito local, considera el procedimien- 
to papelmojado que definimos anteriormente en este mismo capítulo. La va- 
riable controlada de su bucle for, índice, se hizo local para papelmojado. (No 
supone derroche alguno de memoria el tener montones de variables locales se- 
paradas que actúen como variables controladas para bucles for; recuerda que 
sólo se adjudica espacio de memoria a las variables cuando se llama a su ruti- 
na.) Así, el procedimiento papelmojado es completamente autónomo. 

Con un poco de suerte, alguna vez habrás tenido la siguiente experiencia. 
Has escrito un programa BASIC de la forma 


100 FORK = 1 TO N 


200 GOSUB 3000 


300 NEXT K 


y te has encontrado con que no funcionaba. Al cabo de horas de frustración, 
has descubierto que la subrutina de 3000 utilizaba también a K en un bucle FOR, 
con el resultado de que la llamada a 3000 antes mencionada trastornaba al bu- 
cle FOR que la incluye. 

Tal vez en aquellos momentos no te hayas considerado especialmente afor- 
tunado, pero ahora encuentras tu recompensa. En PASCAL siempre usarás 
una variable local para controlar a todos tus bucles for, y nunca te tropezarás 
otra vez con el mismo problema. En cambio, si no has aprendido la lección, 
llevarás indudablemente al PASCAL tus hábitos adquiridos en el BASIC, y 
más tarde sufrirás tu castigo. 


Variables no locales 


Si llegas a convencerte de que las variables locales son extremadamente va- 
liosas, no hay duda de que, con el celo exagerado de todo neófito, tratarás 
de hacer un uso excesivo de ellas. De modo que hemos de advertirte que hay 
algunos sitios en los que las variables locales no son apropiadas. Uno de ellos 
quedará ilustrado si nos referimos a la función /eecubo anteriormente utili- 
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zada, que utiliza una variable, leecuenta, para contar los números leídos. Si 
haces a leecuenta local de leecubo, aquélla morirá cada vez que retornes de 
leecubo, perdiendo así su valor. Por tanto, será obligado declarar a leecuenta 
en el programa principal o, si no, en alguna rutina que incluya a leecubo y que 
permanezca activa todo el tiempo que dure el funcionamiento del contador. 
También será necesario inicializar leecuenta a cero antes que se produzca la 
primera llamada a /leecubo. 

El principio general es que no se puede hacer local a una variable si se quie- 
re que su valor se arrastre desde una llamada a la siguiente. 


Repetición o recurrencia 


Una rutina puede llamarse a sí misma. A esto, que es algo extremadamente 
útil, es a lo que se llama repetición, o recurrencia. Más adelante daremos ejem- 
plos de ello. 

También es posible tener un tipo más profundo de recurrencia, conocido 
como repetición, o recurrencia mutua. Consideremos dos procedimientos en 
un programa de ajedrez. Uno se llama MejorJudadadeNegras, y el otro 
MejorJugadadeBlancas. A cada uno de ellos se le pasa, como argumento suyo, 
una representación del estado del juego. La estrategia de MejorJugadadeNegras 
es proponer una jugada posible y llamar entonces a MejorJugadadeBlancas 
para averiguar cuál sería la respuesta a ella. El procedimiento MejorJugadade- 
Blancas hace exactamente lo contrario. Estos procedimientos, que se llaman 
el uno al otro, son un ejemplo de repetición o recurrencia mutua. La repeti- 
ción mutua puede implicar a cualquier número de procedimientos, llamados 
hasta cualquier profundidad. Es claro que ha de haber alguna condición de 
parada o interrupción de la recurrencia, para evitar que ésta se vaya haciendo 
más y más profunda. Así, nuestros procedimientos de ajedrez podrían con- 
templar una profundidad de cuatro jugadas previstas, en cuyo punto se inte- 
rrumpiría la repetición. 

De hecho, nuestra función del MáximoComúnDivisor puede codificarse en 
una forma repetitiva. Esta versión recurrente, a la que hemos dado el nombre 
abreviado de mcd, se declara en la forma siguiente: 


function mcd(número 1: poso0integer;número2:poso0integer):poso0integer; 
(* Equivalente repetitivo de la función MáximoComúnDivisor x) 
begin : 
if número2 = 0 then 
mcd: = númerol 
else 
mcd: = mcd(número2, númerol mod número2); 
end; (x mcd x) 


Esta versión tiene el mérito de funcionar cuando cualquiera de los dos ar- 
gumentos es cero, así que hemos usado el tipo poso0integer en lugar del 
enteropositivo. 

Para ser leales contigo, hemos de advertirte ahora que la recurrencia o re- 
petición es uno de esos medios o facilidades que se describen paradójicamente 
como **muy fácil de usar cuando se sabe hacerlo””. El saberlo lleva cierto tiem- 
po para algunos, y si al echar un vistazo al mcd te sientes algo mareado o ate- 
morizado por las alborotadas aguas que ves ante ti, te sugerimos que viajes 
en avión, volando adelante hasta llegar a la sección titulada “Referencia ha- 
cia adelante”. 

Al resto de los lectores, es decir, a los no atemorizados, se les puede expli- 
car la forma en que funciona el mcd considerando el ejemplo de llamada 


mcd(119, 98) 


La base del algoritmo de Euclides es que el m.c.d. de 119 y 98 es el mismo 
de los dos números 98 y 119 mod 98 (es decir, 21); Si seguimos aplicando este 
proceso iremos obteniendo números cada vez más bajos, hasta que uno de ellos 
sea cero; en este momento, el otro número es la solución. Así, con nuestra fun- 
ción mcd, 


mcd(119, 98) (1) 
llama a 

mcd(98, 21) (2) 
que, a su vez, llama a 

mcd(21, 14) (3) 
que, a su vez, llama a 

mcd(14, 7) (4) 
que, a su vez, llama a 

mcd(7, 0) (5) 


La repetición se interrumpe ahora, porque número2 = 0 es verdadera. Así, 
la llamada más profunda de mcd devuelve el resultado 7 a la llamada (4), la 
cual devuelve el resultado 7 a la llamada (3), y así sucesivamente hasta que 
se devuelve 7 como resultado de la llamada externa. 

Esta es la magia del algoritmo de Euclides. Funcionó perfectamente en la 
antigua Grecia, y todavía sigue haciéndolo en nuestros días. 

La descripción repetitiva que el PASCAL hace del algoritmo es completa- 
mente natural. En realidad, pone de manifiesto que la pesada mano de Frank 
Round había intervenido en nuestro algoritmo original MáximoComúnDivi- 
sor. Este error original, basado en el BASIC, es más difícil de comprender que 
la descripción repetitiva (una vez que uno está acostrumbrado a la repetición). 
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Las variables locales y la repetición 


Como segundo ejemplo de recurrencia o repetición, consideremos la función 


function sumto0: integer; 
var 
número: integer; 
begin 
read(número)); 
if número = 0 then 
sumto0:= 0 
else 
sumto0:= sumto0 + número; 
end; (* sumto0 x) 


Aquí, sumto0 es una función sin argumentos. Se la llama simplemente es- 
cribiendo su nombre. Cuando se mira a la línea 


sumto:= sumto0 + número; 


uno podría pensar que esto no es más que incrementar el valor de sumto0. Sin 
embargo, la sintaxis es bastante engañosa. (Recuérdese lo que dijimos ante- 
riormente: que un nombre de función en el término izquierdo de una asigna- 
ción es algo especial.) La segunda sumto0 es una llamada (repetitiva) a la fun- 
ción. Así pues, la línea significa ““el resultado de la función se obtiene llaman- 
do repetitivamente a sumto0 y añadiendo el valor de número””. 

Antes que expliquemos lo que hace la función, trata de everiguarlo tú mis- 
mo. Considera la sentencia 


writeln(sumto0); 


cuando los datos suministrados para el read están formados por los números 
13, 19 y O. 

La respuesta es que la función sigue leyendo datos hasta que se suministra 
un cero, y entrega como resultado la suma de los números sobre los que ha 
pasado. Equivale exactamente a 


function sumto0: integer; 
var 
número, suma: integer; 
begin 
sum:= 0; 
repeat 
read(número)); 
sum:=sum + número, 


100 


until número= 0; 
sumto0: = sum; 
end; (* sumto0 x) 


Tal vez te sorprenda que una operación tan mundana se pueda expresar 
usando la repetición y, más aún, que la versión repetitiva sea más corta. Sin 
embargo, si hace sólo unos momentos estabas luchando para tratar de averi- 
guar lo que hace, tal vez no creas que la versión repetitiva sea más legible. Es 
más, puede que ni siquiera hayas podido llegar a determinar lo que hace. 

Por si fuera así, explicaremos cómo trabaja esta función. Cuando se la lla- 
ma por primera vez, la función lee el valor 13 y lo pone en número. Como 
número no es cero, la acción siguiente es la que viene después de else. Esto 
hace que se llame a sumto0 en forma repetitiva. Ahora viene el punto que ver- 
daderamente nos interesa destacar en esta sección. Al tener lugar la llamada 
repetitiva, se asigna de nuevo espacio de memoria para número. La asignación 
anterior de número pasa a hibernación..., no podemos hacer referencia a ella, 
porque el nombre número siempre se refiere a la asignación más reciente. Esta 
segunda llamada a sumto0 pone a su número en 19, y el actual tiene el valor 0. 
(Tanto el valor externo como el segundo están en hibernación.) El tercer nivel 
halla ahora que número =0, y retorna desde la llamada actual a sumto0, dan- 
do 0 como resultado de la función. En este punto se libera el tercer número 
y volvemos al segundo nivel. El segundo número pasa a ser el actual y, no 
afectado por su experiencia de haber estado algún tiempo en hibernación, tie- 
ne todavía el valor 19. Se toma de nuevo la sentencia 


sumto0: = sumto0 + número; 


Recuérdese que la llamada repetitiva a sumto0 hizo que ésta quedara en sus- 
penso. Ahora sabemos que el resultado de esta llamada es 0. Así pues, esta 
sentencia suma O a 19, y devuelve el resultado 19 como valor de la segunda 
llamada a sumto0. Estamos otra vez en una situación similar a la de la primera 
llamada, y sumamos 19 a 13, obteniendo 32 como resultado final. Así que el 
efecto de nuestra writeln(sumto0) original es la impresión del valor 32. 

Todo el funcionamiento depende de que número sea una variable local. Si 
la declaramos fuera de la función, no se asignará de nuevo espacio de memo- 
ria cada vez que se llama a sumto0. En lugar de ello, lo que habrá será sólo 
una copia del número. Entonces, el resultado de sumto0 sería siempre 0, y no 
sería una función muy útil. 

Si nuestra explicación anterior ha tenido éxito, te habrá convencido de que 
la repetición y las variables locales, trabajando hombro con hombro, constitu- 
yen una combinación muy potente. Incluso podrás creer al profesor Primple 
cuando mantiene que la repetición es el mecanismo fundamental de la progra- 
mación. Sin embargo, tememos que muchos lectores puedan estar arrepintién- 
dose de no haberse ido con los que tomaron el avión, los cuales están tomando 
tierra precisamente ahora. 
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La referencia hacia adelante 
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Los grandes programas pueden contener cientos de rutinas, docenas de las 
cuales podrían estar declaradas al mismo nivel de anidamiento. Para hacer que 
un programa sea legible, ha de haber un ordenamiento coherente, de modo 
que un lector tenga probabilidades de hallar en la jungla una sentencia deter- 
minada. Un ordenamiento posible es la ordenación alfabética de los nombres 
de las rutinas. Sin embargo, esto nos lleva a un problema que ya hemos men- 
cionado antes: al igual que cualquier otro objeto, el nombre de una rutina se 
ha de declarar antes de usarle. ¿Qué ocurre si el procedimiento abeja llama 
al procedimiento zorro O, peor todavía, si el procedimiento zorro llama tam- 
bién al abeja en forma mutuamente repetitiva? A fin de superar este proble- 
ma, el PASCAL provee un mecanismo para hacer declaraciones adelantadas. 
Ello permite escribir, antes que abeja, la declaración 


procedure zorro(pig: real); 
forward; 


Esto cuenta como una declaración, en el sentido de que zorro está ahora den- 
tro del ámbito y puede ser usado por otros procedimientos. Más tarde habrá 
que dar la declaración íntegra de zorro. Sin embargo, cuando lo hagas, habrás 
de omitir la lista de parámetros, porque ya la has mencionado una vez, y el 
PASCAL se molesta si se menciona dos veces. Así pues, podrías escribir 


procedure zorro; (x* pig: real +) 


var 
(ee 5. 8) 
begin 
(* ... x) 


end; (* zorro x) 


Es una buena idea el repetir la lista de parámetros en un comentario, como 
hemos hecho más arriba, de manera que el programa siga siendo legible, a pe- 
sar de los intentos del PASCAL por impedirlo. 

Similarmente, si piggy es una función que haya de declararse por adelanta- 
do, se puede escribir 


function piggy (pig: real): integer; 
forward; 


(+ 


ES 5%) 
function piggy; (* (pig: real): integer x) 
(* Sigue la declaración propiamente dicha x=) 


Cambio del valor de los argumentos 


Hay una cuestión importante que hasta ahora hemos pasado por alto: si 
se cambia el valor de un parámetro, ¿cambia también el argumento correspon- 
diente? 

Consideremos el siguiente procedimiento: 


procedure númerosredondos (x: integer); 
(* Como veremos, éste es un procedimiento sin utilidad alguna x) 
begin 
x:.= x —x mod 10 (x restar de x el resto de x/10 +) 
end; (x númerosredondos x) 


La finalidad del sencillo procedimiento precedente es convertir a su pará- 
metro x en el múltiplo más próximo de 10 que sea menor que x. Es para ayu- 
dar a aquellas personas ignorantes que no se fían realmente de los números 
y que se sienten más a gusto si los números difíciles como 67 y 63 se expresan 
en “números redondos”” como 60. Podría tal vez discutirse que el 67 se debe- 
ría redondear a 70, pero no importa. 

Sin embargo, el procedimiento no consigue su propósito, porque la regla 
normal en PASCAL es que el parámetro sea una variable local de su procedi- 
miento, y cualquier cambio que se haga en el parámetro no afecta al argumen- 
to correspondiente. Así, en la llamada 


númerosredondos(temperatura); 


el valor de temperatura no cambia. Lo que ocurre es: 


1) se crea una variable local x, que toma el valor actual de temperatura, 
digamos 23; 

2) x toma el valor 20; 

3) al producirse el retorno desde númerosredondos, x muere, con el efecto neto 
de que la llamada a númerosredondos no ha servido absolutamente de nada. 


En este ejemplo concreto, el objetivo deseado se puede conseguir escribiendo 
númerosredondos en forma de función, y no de procedimiento, pero no siem- 
pre será así. 

Para conseguir en todos los casos la meta deseada, lo que hace falta es un 
mecanismo que ordene tratar a un parámetro exactamente como sinónimo de 
su correspondiente argumento, de modo que un cambio en uno ocasione auto- 
máticamente un cambio correspondiente en el otro. El PASCAL dispone pre- 
cisamente de esa facilidad; consiste simplemente en escribir la palabra var de- 
lante de cada parámetro que se haya de tratar como sinónimo. En el caso de 
númerosredondos, su encabezamiento debería escribirse así: 


procedure númerosredondos (var x: integer); 
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Los parámetros sinónimos se llaman parámetros variables (o parámetros 
var), y los no sinónimos se llaman parámetros de valor. El argumento corres- 
pondiente a un parámetro variable ha de ser del mismo tipo que el parámetro. 
Este es uno de los sitios en que no se pueden usar tipos de subrango compati- 
bles, pero diferentes. Es más, el argumento ha de ser (cosa bastante natural) 
una variable. Así, la llamada 


númerosredondos(temperatura + 6); 


no sería correcta. El argumento puede ser, sin embargo, un elemento de una 
matriz o array. (Hablaremos de las matrices más adelante; por el momento, 
limítate a pensar de a[k] en PASCAL como A(K) en BASIC.) Un ejemplo es 


númerosredondos(a[k]); 


El efecto aquí es que se calcula el valor de k en el momento de la llamada a 
númerosredondos (supondremos que tiene el valor 6), y entonces se trata a su 
parámetro como sinónimo del elemento a[6] de la matriz o array. 

Aunque todavía no hemos llegado al estudio completo de las matrices, vale 
la pena mencionar aquí que pueden pasar como argumentos matrices enteras, 
y que en este caso el parámetro correspondiente es normalmente un parámetro 
variable. Esto sería aplicable, por ejemplo, a un procedimiento invert, que in- 
virtiese una matriz o array suministrada como argumento. 

Nuestros procedimientos númerosredondos e invert nos sirven para traer 
a colación una valiosa técnica de programación. Si un procedimiento tiene pa- 
rámetros variables, puede ser autónomo, y, sin embargo, podrá todavía co- 
municar sus resultados al mundo exterior a él. 


Las rutinas como parámetros 


Muy de vez en cuando, es útil usar el nombre de una rutina como paráme- 
tro para otra. Por ejemplo, puedes desear llamar a un procedimiento 


integrate(f); 
en donde f es el nombre de una función. El PASCAL tiene un mecanismo pa- 
ra esto, pero el informe PASCAL difiere de la norma PASCAL, y, lo que es 


más, algunos compiladores difieren de ambos. Por tanto, si tienes necesidad 
de este tipo de facilidad, habrás de consultar tu manual local. 


Construyendo bloques 


Cerramos este capítulo hablando de un punto general relacionado con el 
estilo de programación. Este punto va dirigido a aquellos lectores que sólo ten- 
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gan experiencia de los mecanismos (carentes de parámetros) GOSUB y RE- 
TURN del BASIC mínimo y que, en consecuencia, tal vez no puedan apreciar 
inmediatamente todos los beneficios de su recién hallada libertad. 

Cuando te veas enfrentado a un difícil problema de programación, es pro- 
bable que lo resuelvas por medio de una combinación de métodos “*descen- 
dentes” y ““ascendentes”” (top down, o de arriba abajo, y bottom up, o de aba- 
jo arriba). El método descendente, o de arriba abajo, consiste en comenzar 
con el problema global y dividirlo continuamente en subproblemas, hasta que 
estos subproblemas sean fáciles de programar, el método de refinamiento pro- 
gresivo resume este proceso. El método ascendente, o de abajo arriba, supone 
la clasificación y separación de los detalles de bajo nivel y su encapsulación 
en rutinas. Estas rutinas se pueden emplear a continuación para atacar a los 
problemas del nivel de detalle inmediato superior, y así sucesivamente. El en- 
foque de abajo arriba sólo es adecuado cuando se sabe la dirección en la que 
se va. 

Los estilos de programación varían, pero un enfoque típico consiste en usar 
el método descendente para reducir el problema a partes susceptibles de ser 
tratadas, y luego emplear el método ascendente para programar estas partes. 
La elección de las rutinas adecuadas en cada nivel de detalle es una de las habi- 
lidades o artes de la programación. A menudo se eligen mal la primera vez, 
y los programas serán toscos y desmañados. Al cabo de algún tiempo, tu expe- 
riencia te dirá que hay algo que no está bien. Entonces variarás las especifica- 
ciones de algunas de tus rutinas; con suerte, elegirás las que mejor vayan, y 
entonces la programación se convertirá en un sueño. Lo que has hecho es una 
cosa muy importante: has fabricado las herramientas adecuadas para el traba- 
jo en cuestión. 


Las herramientas 


La razón por la que el hombre se considera superior a otros animales es 
porque usa herramientas. Las herramientas han sido la clave del progreso hu- 
mano. Indudablemente, otros animales, cuando piensan en estas cosas, Opi- 
nan lo contrario y se consideran a sí mismos superiores al hombre. Sin embar- 
go, como no es probable que muchos de esos animales sean lectores nuestros, 
aquí seguiremos en la corriente de opinión de la superioridad humana. 

Las herramientas tienen un valor inmenso en la programación, y un buen 
programador sabe, al mismo tiempo, construir buenas herramientas y utilizar- 
las diestramente. Léase un estudio completo de este tema en un libro de Ker- 
nighan 8 Plauger (1981), cuya lectura es un verdadero placer. 

El crear un procedimiento o una función es una forma de construir una 
herramienta. Una vez creada para que realice una tarea en tu programa, pue- 
des utilizar de nuevo la misma herramienta para ayudarte cada vez que surja 
O se repita una tarea igual en cualquier otro lugar del mismo. Es más, si la 
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herramienta en cuestión reúne unas características suficientemente generales, 
puedes incluirla en una biblioteca (caja de herramientas), para su utilización 
en otros programas. 

Por todo ello, lo que aconsejamos a aquellos programadores que deseen 
superarse y destacar sobre los demás es lo siguiente: cuando tropecéis con pro- 
blemas, construid una herramienta autónoma para ayudaros. De ese modo, 
podréis utilizarla de nuevo para vencer los mismos problemas siempre que os 
surjan en el futuro. El construir herramientas no es fácil, pero, como dijimos 
en la sección precedente, cuanto más practiquéis mejores llegaréis a ser. 


Tan cuidadosa del tipo parece... 


TENNYSON, in memoriam, des- 
cribiendo cómo preserva la na- 
turaleza las diversas especies 


Más sobre 
tipos sencillos 
de datos 


Clases de tipos 


Todos los tipos de datos que hemos descrito hasta ahora han sido tipos sen- 
cillos, que tienen un sólo valor. En los capítulos que siguen consideraremos 
otras clases de tipos de datos; en particular, estudiaremos las matrices o arrays, 
que son colecciones de varios objetos. Al ver la expresión “tipo sencillo””, po- 
drías esperar que otros se llamaran “tipos complicados””, pero no hay ningún 
lenguaje de programación que admita jamás que algo es complicado. La idea 
es que otros tipos son sencillos también, aunque no tanto como los así llama- 
dos. Esto se parece un poco a los detergentes para lavar, que vienen en paque- 
tes de tamaños familiar, gigante y tambor. No existe ninguno de tamaño pe- 
queño, individual. 

Antes de pasar a los tipos no tan sencillos, completaremos en este capítulo 
nuestro examen de los tipos sencillos, presentando dos que hasta ahora había- 
mos omitido. Se trata de los tipos Boolean y char. El primero recibe su nom- 
bre del apellido del lógico George Boole (1815-1864), que goza de la impar dis- 
tinción de que su nombre sea escrito miles de veces todos los días por progra- 
madores de todo el mundo. Sin duda, esta conmemoración es mejor que la 
de erguirse en efigie en una plaza urbana, siempre cubierto de palomas. Por 
consiguiente, no regatees a Boolean su mayúscula inicial cuando escribas pro- 
gramas en PASCAL, aun cuando es probable que tu compilador te perdone 
si escribes boolean. 
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Datos Booleanos 
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El tipo de datos Booleano contiene sólo dos valores: verdadero y falso. El 
tipo Booleano existe en forma efectiva en el BASIC, aunque es posible que 
no te hayas dado cuenta de ello. Las expresiones de relación tales como 


Xx > Y 


producen un resultado Booleano. En el PASCAL se puede asignar este tipo 
de expresión de relación a una variable Booleana, por ejemplo: 


var 
xpositivo: Boolean; 
x: real; 

begin 

(xk 


*) 
xpositivo:= x > 0; 


Aquí la variable toma el valor verdadera (true) si x es mayor de cero; en 
caso contrario, es falsa (false). Como dijimos en el capítulo 4, cuando usamos 
una sentencia if (y similarmente una sentencia while, etc.), en PASCAL no nos 
vemos limitados u obligados a escribir una expresión de relación, como hemos 
hecho hasta ahora, sino que podemos escribir cualquier expresión Booleana. 
Una expresión Booleana es igual que una expresión aritmética, sólo que, en vez 
de manejar números, manejamos los valores verdadero y falso. Los operandos 
de una expresión Booleana son expresiones relacionales, variables Booleanas 
o constantes Booleanas. Los operadores son and, or y not; sus significados 
(Y, O y NO) son obvios. A continuación se dan algunos ejemplos del uso de 
expresiones Booleanas: 


var 
xpositivo, xoypositivo, domingo, lloviendo: Boolean, 
X, y, P, q: real; 

begin 

(x« 


- *) 
if xpositivo then (x ... x); 
if not lloviendo then (x ...obsérvese que “not” toma un sólo operando x); 
while domingo and lloviendo do (x ... x); 
xOypositivo: = xpositivo or (y > 0); 
if (not lloviendo or domingo) and (p > q) then (x ... x); 


Obsérvese que en una sucesión de sentencias tal como 


x=15: 

Pp:i= Xx +3; 

xpositivo:= x > 0; 
1= x — 22; 


la última sentencia, que cambia a x, no cambia el valor de xpositivo (que sigue 
siendo verdadero), por la misma razón que no cambia el valor de p. 
Observa también que si hallas en tu programa algo como 


if xpositivo = true then (x ... +); 


debes suprimirlo, porque fue el taimado Frank Round el que lo puso. Lo de 
= true es completamente redundante. 

La finalidad de las variables Booleanas debe ser evidente. Hacen que los 
programas sean más fáciles de leer y comprender. Los programas BASIC típi- 
cos están muchas veces oscuros y confundidos por las variables numéricas que 
adoptan sólo los valores 0 y 1, por lo que son realmente Booleanas. Tu pro- 
grama BASIC puede contener, por ejemplo, una variable K5 que es 1 si se ha 
realizado una determinada inicialización, y O si no se ha hecho. Similarmente, 
una variable M puede ser 1 si han de imprimirse mensajes, y O en los demás 
casos. Parte del programa BASIC puede decir: 


500 IF K5 = 1 THEN 600 
510 LET K5 = 1 
realiza la inicialización 


600 ... 


800 IF K5 = 0 THEN 900 
810 IF M = 0 THEN 900 
820 PRINT ““INICIALIZACION REALIZADA” 


900 ... 


Esto se puede escribir en PASCAL (usando incializado en lugar de KS y 
enviomensajes en lugar de M) en esta forma: 
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var 
inicializado, enviomensajes: Boolean, 

begin 

(x 


. kx) 
if not inicializado then 
begin 

inicializado: = true; 
(x*  ...realiza inicialización... *) 
end; 
(x* 


. *k) 
if inicializado and enviomensajes then 
writeln(““inicialización realizada”); 


Datos de carácter 
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Una variable PASCAL del tipo char puede tomar como valor cualquier ca- 
rácter aislado. No es, por consiguiente, como una variable de cadena o string 
en BASIC, cuyo valor consiste en una sucesión de varios caracteres, pero sin 
embargo se puede usar como bloque fundamental de construcción, a partir del 
cual se pueden hacer cadenas. Las cadenas (strings) del PASCAL se tratan en 
el capítulo siguiente. 

Todo lenguaje de programación que soporte caracteres o strings tiene un 
Juego de caracteres asociado. Este especifica el conjunto de caracteres permi- 
sibles y la petición de los caracteres individuales. En todo juego de caracteres 
las letras vienen en orden alfabético; así, invariablemente, *B” es siempre ma- 
yor que “A”. Sin embargo, los juegos de caracteres pueden diferir, por ejem- 
plo, en cuanto a si *+>” es mayor que “A”; o, incluso, si “a? es mayor que “A”; 
por consiguiente, si nos fiamos de una forma de petición determinada, esta- 
mos cortejando al peligro. Los primeros sistemas ordenadores tenían frecuen- 
temente juegos de caracteres muy limitados, basados en los equipos perfora- 
dores de tarjetas, pero un compilador y un sistema operativo modernos deben 
soportar suficientes caracteres para atender a la mayor parte de vuestras nece- 
sidades. Ello es bueno si la petición de caracteres está basada en una norma 
aceptada, tal como el código ASCII. 

Una constante char, exactamente igual que una cadena o string de caracte- 
res, va entre las comillas sencillas, es decir 


4? 


a 


Por tanto, al pasar del BASIC al PASCAL, tienes que devaluar todas las co- 
millas al 50 por 100. 
En las líneas que siguen se muestran algunos usos de una variable char: 


var 
clavedeclase: char, 

begin 

(xk 


. *) 
clavedeclase: = “a 
if clavedeclase = “b” then (x ... x) 
case clavedeclase of (x* char y case van juntos frecuentemente x) 


, 


“a: (x ... x); 

De: (xk... ); 

CC, Ur (x ... ); 
end; 


Operaciones con los tipos sencillos 


Hemos visto ya los cuatro tipos sencillos incorporados en el PASCAL : real, 
integer, Boolean y char. Estos se pueden complementar con tipos definidos 
por el usuario; en el resto de este capítulo usaremos como ejemplo de tipo de- 
finido por el usuario 


animal = (ratón, perro, león); (* en orden creciente de fiereza x) 
Además, un subrango de cualquier tipo sencillo es también un tipo sencillo. 


Con cada tipo de datos van asociados algunos operadores que se pueden 
aplicar a los objetos de dicho tipo. Estos operadores son: 


real *F/+,— 
integer *, div, mod, +, — 
Boolean and, or, not 

char (ninguno) 


La anotación de ““ninguno”” frente a char no significa que este tipo carezca 
de utilidad. Los operadores relacionales o de relación (por ejemplo, >, etc.), 
al ser polimórficos, se pueden aplicar a todos los tipos sencillos (y siempre dan 
un resultado Booleano); además, el operador de asignación, por ejemplo, 


a:= b; 
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se puede aplicar a cualquier tipo de datos (excepto a los archivos, véase el ca- 
pítulo 9). En general, cuando un operador tenga dos operandos (es decir, para 
cualquiera de los operadores anteriores excepto not), estos dos operandos han 
de ser del mismo tipo de datos, aunque, como ya hemos dicho, los integers 
y los reals se pueden entremezclar bastante. 

El PASCAL no nos permite hacer cosas excéntricas, como efectuar la ope- 
ración lógica and con dos números reales (reals), o decir 


(1/2) x true 


El PASCAL no se ocupa de medias verdades. 
Puedes construir fácilmente expresiones PASCAL ricas en diferentes ope- 
radores, como 


a:= b> cornotdandf; 


Hay un conjunto de reglas de precedencia para determinar el orden en que 
se realizan o ejecutan los operadores. Por ejemplo, las reglas dicen que la asig- 
nación anterior equivale a 


a:= b > (cor ((not d) and f)); 


lo que tal vez te sorprenda. (El not se hace en primer lugar, luego el and y 
luego el or; los operadores relacionales tienen la precedencia más baja). 

Sin embargo, si no estás seguro de la precedencia relativa de dos operado- 
res, no consultes el informe PASCAL para ver cuáles son las reglas. Simple- 
mente, pon en tu expresión los paréntesis que hagan falta para dejar bien claro 
lo que quieres decir. Como resultado de ello, los lectores de tu programa no 
tendrán que tratar de adivinar qué es lo que éste pretende hacer. 


Juegos de valores ordenados 
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Todos los tipos sencillos están representados por un juego de valores orde- 
nado. En la tabla que sigue se muestran los miembros primero, segundo y últi- 
mo del juego de valores asociado con algunos tipos sencillos de datos: 


Tipo de datos Primer valor Segundo valor Ultimo valor 


integer —maxint —maxint+1 maxint 
Boolean false true true 
char (definidos por el juego de caracteres) 
animal ratón perro león 
1..10 1 2 10 


El tipo de datos real es excepcional. ¿Cuál es el número real que sigue a 
2.0? La respuesta es que ello depende enteramente de la exactitud de la máqui- 
na que estés utilizando. A diferencia de la mayoría de nosotros, un compila- 
dor PASCAL puede prohibir aquellas preguntas a las que no sea capaz de dar 
una contestación satisfactoria; y, como veremos, se aprovecha bien de ello. 

Los operadores relacionales del PASCAL utilizan estos juegos ordena- 
dos de valores. El PASCAL soporta también varias funciones incorporadas, 
además de aquellas con equivalentes en BASIC que ya hemos mencionado. 
Varias de ellas se refieren a los juegos ordenados de valores. Una bastante im- 
portante es 


ord(x) 


que da el “número ordinal”” de x en el juego de valores definido por el tipo 
de datos de x. El primer valor del juego tiene el número ordinal 0, el segundo 
tiene el número ordinal 1, y así sucesivamente. Así, un ejemplo usando nues- 
tro tipo animal, si la variable bestia estuviese establecida por el programa 


var 
bestia: animal, 

begin 

(x 


*) 
bestia: = perro; 


entonces ord(bestia) sería 1, porque perro es el segundo valor en la sucesión 
ordenada de valores en el tipo de datos animal. 

Si x es del tipo char, ord(x) da la posición de x en la ordenación definida 
por el juego de caracteres. Para hacer la traducción inversa a ord, hay una 
función ckr que produce un resultado char; esta función es tal que 


chrtord(c)) es idéntico a c 


para cualquier carácter c. Por tanto, la función chr es idéntica a la CHR$ que 
se encuentra en algunos BASIC, y, cuando se aplica a un argumento de carác- 
ter, el ord del PASCAL es como el CHR o el ASC del BASIC. 
Finalmente, aunque no es posible sumar ni restar uno de, por ejemplo, una 
variable char, se puede conseguir el efecto equivalente con las funciones succ 
y pred, que significan sucesor y predecesor, respectivamente. La primera es 
tal que succ(x) es el sucesor de x en el tipo de datos definido por x. Así, succ(2) 
es 3, y, lo que nos viene más al caso, succ(ratón) es perro, dada la definición 
de animal expresada más arriba. La función pred hace lo contrario que la succ. 
Si se pregunta por el succ o el pred de un número real, el PASCAL, como 
ya hemos advertido de antemano, declarará que la pregunta es improcedente. 


115 


El control de los bucles 
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En algunos ejemplos precedentes hemos venido usando succ y pred de una 
manera implícita. Ello es así porque for ... to emplea el succ, y for ... downto 
usa el pred para alterar la variable controlada. El resultado de esto es que la 
sentencia for es mucho más potente y tiene un carácter mucho más general de 
lo que su empleo con enteros (integers) muestra. Se puede decir 


for bestia: = ratón to león do 


en cuyo caso bestia tomará sucesivamente los valores ratón, perro y león. Si- 
milarmente, 


for bestia: = león downto perro do 


dará a bestia sucesivamente los valores león y perro. En un ejemplo más 


*) 
for ch:= “a? to Z* do 

write(ch); (* write(ch) es como PRINT C$; en BASIC x) 
writeln; (* esto da salida a un carácter de cambio de línea x) 


imprime la línea 


abcdefghijklmnopqrstuvwxyz 

siempre que las letras, de “a” a **z””, se encuentren adyacentes en el juego de 
caracteres. En algunos juegos de caracteres, notablemente en el EBCDIC, hay 
caracteres adicionales, bastante peculiares, intercalados entre algunas parejas 
de letras. 

En la mayoría de las aplicaciones se hallará amplio campo para el uso de 
bucles for de carácter general. No dejes que el Sr. 869704 te prive de la posibi- 
lidad de ser creativo al confinarte a los bucles for numéricos. 


No te «encadenes» demasiado... 


Consejo de RICARDO IT para usua- 
rios insatisfechos de PASCAL 


Matrices (arrays) 
y cadenas (strings) 


Conceptos básicos 


Las referencias de matrices son básicamente similares en el BASIC y el PAS- 
CAL, con la salvedad de que este último encierra las listas de subíndices entre 
corchetes, en vez de hacerlo entre paréntesis; es decir, el A(J,K) del BASIC se 
convierte en el a[j,k] del PASCAL. El PASCAL no sólo permite las matrices de una 
o dos dimensiones, como el BASIC, sino también las de tres y más dimensiones. 

En el PASCAL no existe equivalente directa de la sentencia DIM; en lugar 
de ello, las matrices o arrays se declaran en la sección var, exactamente igual que 
cualquier otra variable. Para lograr el efecto equivalente al de 


DIM A(10), B(5,6) 
se dice 
var 
a: array [0..10] of real; 


b: array [O..S, 0..6] of real; 
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Si se desea que los límites inferiores sean 1 en lugar de O, se puede cambiar 
por 1 el 0 correspondiente en la declaración anterior. En realidad, se puede, si 
se desea, hacer que el límite inferior sea cualquier otro entero (integer), como 4, 
o incluso — 4. 

Sin embargo, el uso de enteros como límites sólo nos da un atisbo de la gene- 
ralidad del PASCAL. Tal vez esto te sorprenda, pero, cuando declares una ma- 
triz o array en PASCAL, tienes que dar un tipo de datos para especificar cada 
par de límites. En nuestros ejemplos anteriores usamos tipos que son subrangos 
del tipo integer, por ejemplo 0..10. El tipo podría haber sido igualmente uno de- 
finido por el usuario, el tipo char o el Boolean, o un subrango de cualquiera de 
ellos. (El único tipo sencillo que no se permite es el real.) No dejes que el 
Sr. 869704 te engañe haciendo que todos los subíndices de tus matrices sean ente- 
ros O integers. 

Con cada matriz van asociados por lo menos dos tipos de datos. Son el tipo 
de datos de componente, que es el tipo de datos de los elementos de la matriz 
y el tipo de datos de índice, que es el tipo de datos de índice de la matriz. 

Según esto, en 


c: array [“2”..77 of Boolean; 


el tipo de datos de los componentes es Boolean, y el tipo de datos de índice es 
un subrango de char. La elección del tipo para el índice no tiene relación alguna 
con el tipo de los componentes. Si la matriz o array tiene varias dimensiones, puede 
tener varios tipos de índice distintos, por ejemplo: 


ecount: array ['a”..z' Boolean] of 0..1000; 


Dada la declaración precedente, se puede acceder a los elementos de ecount, 
que desde luego son enteros en el margen de O a 1000, por medio de subíndices 
tales como 


ecount ['p”, false] 


Las matrices tales como ésta no son un capricho. Supongamos que tenemos el 
problema de contar, en un texto dado, por cada letra de la “a” a la “z”: 


1) El número de palabras que comienzan con la letra dada y terminan con la “e” 


2) El número de palabras que comienzan con la letra dada y no terminan con 
la “e”. 


En tal caso, la matriz o array ecount es justamente la estructura de datos que ne- 
cesitamos para nuestro contaje. Tomando como ejemplo la letra “p””, el elemento 


ecount[ 'p”, true] 


mide el número de palabras que comienzan con “p”” y terminan con “e”. El ele- 
mento false correspondiente cuenta el número de las que no acaban en “e”. El 


siguiente fragmento de programa muestra la forma en que se podría actualizar 
ecount: 


var 
primercar: char; (« primer carácter de la palabra actual x) 
ultcar: char, (* último carácter de la palabra actual x) 
termicone: = Boolean; 
ecount: array['a”..Z?, Boolean] of 0..1000; 

begin 

(x 


.  *) 

(* Supóngase que en este punto se han fijado primercar y ultcar «) 
termicone:= ultcar= “e”; 
ecount[primercar, termicone]: == ecount[primercar, termicone] + 1; 


Gr 
*) 


Piénsese en este ejemplo, y considérese cómo se podría programar lo mismo 
en BASIC. Ello debe poner de relieve varias de las lecciones que venimos tratan- 
do de enseñar en este libro. 


Bucles con matrices 


Dado que en el PASCAL normalmente se accede a los arrays o matrices den- 
tro de bucles, es verdaderamente una suerte que las matrices y las sentencias for 
casen tan bien. Recuérdese que, lo mismo que el tipo de índice de una matriz 
no tiene por qué ser un entero o integer, tampoco necesita serlo la variable con- 
trolada para un for. Como ejemplo del uso de tipos de datos no enteros, la sen- 
tencia que sigue inicializa a cero todos los elementos de ecount. 


for fila:= “a” to Z” do 
begin 
ecountl[fila, false]: = 0; 
ecountl[fila, true]: = 0; 
end; 


en la que fila se declara como un variable del tipo char. De hecho, esta inicializa- 
ción se puede escribir empleando un bucle anidado, que abarca los dos valores 
false y true. Esto se hace en la forma siguiente: 
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for fila:= “a? to Z? do 
for column: = false to true do 
ecountl[fila, column]: = 0; 


en la que column es una variable de tipo Boolean. Tal vez recuerdes que en PAS- 
CAL todos los tipos de datos son conjuntos ordenados y que, en el caso del Boo- 
lean, el false está definido un tanto arbitrariamente como menos que el true, co- 
mo indicaba nuestra tabla del capítulo 6. (Si quieres una ayuda mnemotécnica, 
recuerda que si una sentencia es ““menos que verdadera”, es falsa.) 


Un aparte acerca de la detección de errores 


Como ejercicio sobre los efectos de los errores, vale la pena considerar el efecto 
que tendrá el escribir por error los límites false y true en el orden quivocado, es 
decir, 


for fila:= “a? to Z? do 
for column:= true to false do 
ecount[fila, column]: = 0; 


Los bucles nulos son completamente aceptables en PASCAL, al igual que en 
BASIC. Por tanto, el efecto del bucle precedente no sería inicializar a ecount, 
sino no hacer absolutamente nada, porque el bucle interno es nulo. 

Afortunadamente, la mayoría de los compiladores PASCAL comprueban si 
existen variables no asignadas, es decir, el uso de variables a las que no se haya 
dado un valor. Por tanto, la primera vez que intentases usar un elemento de ecount 
recibirías un mensaje de error. Sin embargo, ésta suele ser una facilidad opcional, 
y muchos programadores precipitados la desconectan para que Perkins no inter- 
venga y sus programas se ejecuten más rápidamente. En este caso, en el pecado 
llevarían la penitencia: en lugar de darles errores, sus programas correrían a gran 
velocidad produciendo respuestas completamente aleatorias, porque ecount em- 
pezaría con valores aleatorios. 


Declaración de los tipos de índice 
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En la mayoría de los casos, el tipo de índice de una matriz o array será un 
tipo de subrango, tal como 


Es útil seguir el consejo que dimos anteriormente, declarando tales tipos de 
subrango en la sección type del programa, y dándoles los nombres apropiados, 
por ejemplo: 


type 
letras= “a”..z'; 
vuelta= 1..10; (x* suponiendo que el array representa tiempos para una 
vuelta en una carrera de 10 vueltas a una pista x) 


Las ventajas que esto tiene son de dos clases. En primer lugar, puede haber 
varias matrices o arrays relacionadas entre sí, todas las cuales compartan el mis- 
mo tipo de índice. Al declarar el tipo por separado, se hace más fácil el cambio. 
Por ejemplo, podríamos cambiar vuelta a 0..12, y todas las matrices que utiliza- 
ran vuelta cambiarían de tamaño conforme a ello. Mejor aún, podríamos ir un 
paso más adelante en la asignación de nombres y utilizar una const llamada nú- 
merodevueltas para representar nuestros 10 ó 12. Esta constante podría utilizarse 
en bucles for que se aplicasen a los arrays con el tipo de índice lap. Usando estas 
ideas podríamos tener un programa como el siguiente: 


const 
númerodevueltas = 10; 
type 
vueltas;= 1..númerodevueltas, 
(x Llevaremos a la asignación de nombres un paso más adelente y daremos 
un nombre a nuestro tipo de array x) 
tiemposdevuelta = array [vueltas] of real; 


var 
vueltasdeliebre: (x tiempos de vuelta para la liebre x) 
tiemposdevuelta; 
vueltasdetortuga: (x tiempos de vuelta para la tortuga +) 
tiemposdevuelta, 
cuentavueltas: (* variable usada como índice para *) 
vueltas, (* riemposdevuelta x*) 
begin 


for cuentavueltas:= 1 to númerodevueltas do (* mete los tiempos de 
vuelta x) 
read(vueltasdeliebre[cuentavueltas], vueltasdetortuga|cuentavueltas)); 
(e 


*) 


La segunda ventaja que tiene el dar un nombre al tipo de índice es que se 
puede declarar que cualquier variable que se use como índice para una matriz 
o array es del tipo de índice en cuestión (véase cuentavueltas en el ejemplo prece- 
dente). Esto proporciona más seguridad. Sin embargo, nos lleva a hacer un co- 
mentario que nos duele anotar. Aunque Perkins es un tipo admirable y todo lo 
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que hace es con intención de ayudar, verdaderamente hay veces en que resulta 
un poco molesto. Una de estas ocasiones se produce cuando hay una variable 
cuyo tipo de subrango es justamente un poco pequeño. Más abajo mostramos 
un ejemplo de esto. El ejemplo ilustra también un valioso artificio de cálculo 
que se llama una pila o stack. Si nunca te has tropezado con pilas o stacks, 
no te preocupes; a pesar de ello, podrás comprender lo que pretendemos con nues- 
tro ejemplo. Este es así: 


const 

tamañopila= 100; 
type 

margenpila = 1..tamañopila; 
var 


pila:array[margenpila] of integer; 
partesuperiorpila:margenpila; 

begin 
partesuperiorpila: = 1; (* vacía la pila inicialmente «+) 


ES 


. *) 
(* Ahora se incrementa la partesuperiorpila, comprobando si se rebasa la 
capacidad (overflow) x) 
partesuperiorpila: = partesuperiorpila + 1; 
if partesuperiorpila > tamañopila then (* ...da mensaje error... 3); 
(x 


0) 


La cuestión es que si partesuperiorpila llega a ser igual a tamañopila, Perkins 
saltará en nuestra ayuda en cuanto intentemos incrementar partesuperiorpila 
y parará el programa allí y entonces. Desde luego, no se da cuenta de que la 
sentencia inmediata verifica si existe este error. Por tanto, deberíamos haber 
declarado partesuperiorpila como 


partesuperiorpila: 1..tamañopila + 1; (x* ¡Pero no! x) 


Desgraciadamente, esto no está permitido. El Sindicato de Operadores de Cons- 
tantes de PASCAL, cuyos miembros trabajan altruistamente dentro de los com- 
piladores de PASCAL tratando de hacer que los miserables programas que mete- 
mos en ellos lleguen a tener algún sentido, exigen que los límites de subrango sean 
constantes. Una expresión tal como 2 + 2 es demasiado, y sus miembros interrum- 
pen el trabajo inmediatamente. Para aplacar al Sindicato, tendríamos que revisar 
el principio de nuestro programa para que dijera: 


const 
tamañopila = 100; 
tamañoexcespila = 101; (* tampoco aquí permite el Sindicato que se 
emplee una expresión «+) 


(+ 
*) 
var 


partesuperiorpila: 1..tamañoexcespila; 


Así pues, para volver a nuestro original, algunas veces es útil declarar que 
las variables empleadas como subíndices de arrays son del tipo de índice de array. 


Sentencias MAT 


“Me estoy dando cuenta de que esta libre elección de los tipos de índice 
tal vez podría, en algunas circunstancias limitadas, servir quizá un poquitín 
de ayuda”, dijo Bill, acumulando así sobre el PASCAL mayores alaban- 
zas que en ninguna ocasión anterior, “pero, ¿cómo los usas con las senten- 
cias MAT?” 


Como sin duda sabes, hay varios BASIC que ofrecen las sentencias MAT, 
permitiendo operaciones tales como 


MATA = B+C 


en la que A, B y C son matrices o arrays. 

Para contestar a la pregunta de Bill —que, sin duda, sabía ya la respuesta 
cuando preguntó—, hay que decir que en el PASCAL no hay equivalente alguno 
de las sentencias MAT. Hay que escribir integramente todas las operaciones de 
matrices, usando sentencias for y demás. 

La única excepción es que se puede asignar una matriz a otra, es decir, lo 
equivalente a 


MATA = B 


en BASIC. Esto sólo se puede hacer cuando las dos matrices sean idénticas en 
cuanto al tipo de componentes y al (los) tipo(s) de índices. Y se consigue por me- 
dio de una sentencia ordinaria de asignación, por ejemplo: 


a:= b; 


Algunos compiladores de PASCAL tienen una regla muy estricta (a la que 
en el capítulo próximo se denomina de “equivalencia de nombre””), en virtud de 
la cual las matrices sólo son idénticas si están declaradas usando un identificador 
de tipo idéntico, como ilustra el ejemplo siguiente: 
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type 
recorridos = array [1..4] of integer; (* puntuaciones en un torneo de 
golf x) 
var 
a: recorridos, 
b: recorridos, 
c: array [1..4] of integer; 
begin 
(+ 


. *) 
a:= b; (* es legal, porque a y b tienen tipos idénticos +) 
(x ..pero c:= b; es ilegal, porque b y c no son de tipos idénticos «*) 


Esto refuerza nuestro consejo acerca de la conveniencia de declarar los tipos 
y de darles nombres. Al hacerlo, informas al compilador, y al lector de tu pro- 
grama, acerca de cuáles son los objetos iguales y cúales los que difieren. 


Matrices de matrices 
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No existe restricción alguna en cuanto al tipo de componentes de una matriz. 
Por tanto, al igual que puedes tener matrices de números reales, Booleanas, etc., 
puedes tener matrices de matrices. En efecto, puedes expresar cualquier matriz 
bidimensional como una matriz unidimensional cuyo tipo de componente es, a su 
vez, una matriz unidimensional. Así, una alternativa a la declaración de ecount es: 


newecount: array [“2”..Z7] of array [Boolean] of 0..1000; 
(x* en lugar de 
ecount: array ['a”..Z?, Boolean] of 0..1000; x+) 


Entonces, para hacer referencia a los elementos individuales de newecount se usan 
dos juegos de corchetes, por ejemplo: 


newecount['p? [false] 
Esto, por sí solo, no supone beneficio alguno (en realidad, probablemente consi- 
deres la idea un tanto retorcida), pero una matriz de matrices es útil en cuanto 
que te permite asignar submatrices o subarrays de la matriz (llamadas ““rebana- 
das” o slices), unas a otras, o a otras matrices del mismo tipo. Por ejemplo: 


newecount['c]: = newecount['k”?; 


Si imaginas una matriz con sus filas y columnas, en las que el primer subíndice 
da la fila y el segundo la columna, la sentencia anterior asigna una fila de newe- 


count a otra. En este caso las filas sólo contienen dos elementos, de modo que 
la asignación es equivalente, en la notación antigua, a 


ecount['c”, false]: = ecount['k”, false]; 
ecount['c”, true]: = ecount[“k”, true]; 


Nuestro ejemplo de matriz bidimensional se puede generalizar a cualquier nú- 
mero de dimensiones. Así, puedes tener matrices de matrices de matrices, o ma- 
trices unidimensionales de matrices bidimensionales, y así sucesivamente. 


Un ejemplo 


Para darte una idea un poco más completa del uso de las matrices o arrays 
en PASCAL, vamos a mostrarte ahora un programa algo más largo. En este 
ejemplo eludimos los conceptos complicados, como las matrices de matrices, 
y nos ceñimos a lo básico. 

El programa ha de hacer los siguientes cálculos. Algunos datos consisten 
en el número de calorías que una persona que trata de adelgazar consume en 
cada día de la semana (empezando por el lunes) durante cinco semanas conse- 
cutivas. Cada semana tiene un “día peor””, aquel en que el sujeto consume 
mayor número de calorías. El programa lleva la cuenta para el lunes, el mar- 
tes, etc., del número de veces que dicho día de la semana ha sido el peor. 

Las personas que tratan de adelgazar no sólo necesitan que se les avisen 
sus fallos; también necesitan estímulos. Aunque su ingestión de calorías pueda 
haber aumentado en una semana determinada, pueden tener la ligera compen- 
sación de haber consumido 20 calorías menos en un día concreto, en compara- 
ción con el mismo día de la semana anterior. Por tanto, el programa les infor- 
ma de cuál ha sido el mayor avance (es decir, la mayor reducción en el consu- 
mo de calorías) en un día de la semana actual, en comparación con el día co- 
rrespondiente de la semana anterior. Durante la primera semana, sin embar- 
go, es evidente que no se puede imprimir esta cifra comparativa. Aquí tienes 
el programa: 


program adelgazador(input, output); 
type 
día = (lunes, martes, miércoles, jueves, viernes, sábado, domingo); 
ingestacal = 0..9999; (+ ingestión calórica del día x) 
cuentascal = array [día] of ingestacal, 
var 
calorías: cuentascal; («* cuentas calorías semana actual x) 
ultcal: cuentascal;, (+ cuentas calorías semana anterior x) 
cuentapeor: array [día] of integer; 
díapeor: día; 
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hoy: día; 

avance: integer; 

mejoravance: integer; 

semana: integer; 

primerasemana: Boolean; 
begin 


(« xxx 1: inicialización x*x*x*x* x) 
primerasemana: = true; 
for hoy: = lunes to domingo do (x inicializa cuentas día peor x) 
cuentapeor[hoy]: = 0; 


(x rex 2; bucle principal para realizar cálculos semanales +xx* >) 


for semana:= 1 to 5 do 
begin 
for hoy:= lunes to domingo do (x lee los datos +) 
read(calorías[hoy]); 
díapeor: = lunes; (x* valor inicial +) 
if not primerasemana then 
mejoravance: = últimascalorias[lunes] — calorías[lunes]; 
for hoy: = martes to domingo do 
begin (x actualiza como sea necesario a díapeor y/o mejoravance +) 
if calorías[hoy] > calorías[díapeor] then 
díapeor: = hoy; 
if not primerasemana then 
begin (* compara con semana anterior x) 
avance: = últimascalorias[hoy] — calorías[hoy]; 
if avance > mejoravance then 
mejoravance: = avance; 
end; 
end; (x* para el bucle x) 
(x Al fin de semana: 
imprime díamejor y actualiza cuentas de díapeor «) 
if primerasemana then 
primerasemana: = false 
else 
writeln(*Mejor avance en semana”, semana, “fue”, mejoravance); 
cuentapeor[díapeor]: = cuentapeor[díapeor] + 1; 
últimascalorías: = calorías; (x* una asignación de matriz «) 
end; (* buéle semanal x) 


(x« xxxx* 3: impresión final x*xx*x* *) 


writeln; 
writeln(“El número de veces que cada día ha sido el peor es el siguiente”); 
for hoy: = lunes to domingo do 
writeln(cuentapeor[hoy]); 
end; 


Con estos datos 


1596 1789 1500 2198 2709 1608 1763 
1754 3408 2316 1908 1965 2076 1543 
2409 987 1543 1765 1289 2341 1913 
1720 1523 1482 1723 2178 1523 1478 
3001 981 1234 2900 2709 2510 2301 


el programa adelgazador produciría la salida 


Mejor avance en la semana 2 fue 744 
Mejor avance en la semana 3 fue 2421 
Mejor avance en la semana 4 fue 818 
Mejor avance en la semana 5 fue 542 
El número de veces que cada día ha sido el peor es 

2 

l 

0 

0 

2 

0 

0 


Podrías introducir mejoras en la lógica de este programa. Tal como está, 
si dos días son igual de malos, el programa sólo cuenta el primero (cronológi- 
camente) de ellos, dando así cierto sesgo a los resultados. También podrízs me- 
jorar la impresión, como explicaremos al final del capitulo 9. 


Malas noticias 


Si tú, lector, tienes muchos conocimientos de los lenguajes de programa- 
ción, tenemos que darte algunas malas noticias. En cambio, si tu experiencia 
está limitada a los simples BASIC, puedes seguir sonriendo algún tiempo to- 
davía, pues te parecerá que el impacto inicial de la tragedia se ha producido 
en un país lejano. Ñ 

La mala noticia es que el PASCAL no provee mecanismo alguno para ma- 
trices o arrays de tamaño variable. Para los usuarios del BASIC, esto equivale 
a decir que no existe 


DIM X(N) 


en donde N sea una variable; en realidad, esto no debe constituir ninguna sor- 
presa. Sin embargo, en muchos otros lenguajes están permitidas las matrices 
de tamaño variable, y su ausencia en el PASCAL será una decepción para al- 
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gunos (aunque esto ya se les advirtió cuando comentamos anteriormente las 
reglas del Sindicato). 

Una vez dada esta noticia, surge una cuestión más. ¿Es posible escribir un 
procedimiento cuyo parámetro sea una matriz o array de tamaño variable? Cier- 
tamente, sería muy valioso para escribir un procedimiento que (por ejemplo) 
invirtiera una matriz de cualquier tamaño. Un procedimiento que pueda in- 
vertir sólo matrices de 5 x 5 es mucho menos útil. 

Desgraciadamente, la respuesta a esa pregunta no es definitiva. El llamado 
“Nivel 1” de la norma del PASCAL (aunque no el informe sobre el PASCAL) 
permite que los parámetros matriciales sean de tamaño variable, pero harán 
falta varios años para que los compiladores existentes y en uso se modifiquen 
para adaptarlos a una nueva norma. Lo que es aún peor, existen por ahí mu- 
chos compiladores que permiten los parámetros matriciales de tamaño varia- 
ble, pero lo hacen en una forma distinta de la forma de la norma. Por tanto, lo 
único que podemos ofrecerte es el consejo, un tanto vacuo, de que consultes tu 
manual PASCAL local, y que tengas cuidado con los problemas de portabilidad. 

Otra restricción que tiene el PASCAL es que una función ha de producir 
como valor un tipo sencillo. Por tanto, no puede producir una matriz, aun- 
que, como se verá en la próxima sección, puede asignar un valor a una matriz 
que se haya pasado como argumento. 


Ejemplo de un parámetro matricial 
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El siguiente ejemplo muestra el uso de un parámetro matricial. El array 
o matriz es de tamaño fijo, estando constituida por diez elementos. 


type 

vector10 = array [1..10] of integer; 
var 

x: vectorl0; 

y: vectorl0; 


procedure poneracero (var a: vector10); 


var 
Kk: integer; 

begin 
for k:= 1 to 10 do 


a[k]:= 0; 
end; (x* ponecacero *) 
begin 
poneracero(x); (* ejemplo de llamada al procedimiento x) 
poneracero(y); (* otro ejemplo de llamada x) 


ES 


*) 


Este ejemplo nos sirve para ilustrar otro punto. Una importante consecuen- 
cia de la regla relativa a los parámetros var es que, si quieres cambiar cual- 
quiera de los elementos de la matriz pasada como argumento, o todos ellos, 
no tienes que olvidarte del var. Si nosotros nos hubiéramos olvidado de él pa- 
ra el parámetro a de nuestro procedimiento poneracero, los efectos habrían 
sido los siguientes: 


e se habría copiado la matriz argumento, digamos x, en una matriz lo- 
cal llamada a; 


e se pondría a a a cero; 
e al retorno de poneracero, a desaparecería; 


e la matriz original x permanecería sin cambio; de modo que el resul- 
tado neto de la llamada al procedimiento habría sido no hacer abso- 
lutamente nada. (De hecho, este ejemplo reproduce como en un es- 
pejo nuestro ejemplo númerosredondos del capítulo 5.) 


Matrices compactadas (Packed arrays) 


Supongamos que posees dos armarios alternativos para guardar tu ropa, 
cada uno de los cuales contiene un número de cajones de tamaño normaliza- 
do. Un armario tiene cuatro de estos cajones de tamaño normalizado, y el otro 
tiene uno sólo. 

Teniendo en cuenta que tus necesidades en materia de vestuario son más 
bien modestas, puedes introducir todas tus ropas, apretándolas, en el armario 
de un solo cajón. Será difícil sacar la ropa, pero en cambio queda ajustadita, 
compacta, y es fácil de trasladar como un solo conjunto o paquete. La alter- 
nativa es usar el armario de cuatro cajones, poniendo calcetines en el primero, 
camisas o blusas en el segundo, y así sucesivamente. Ahora será más fácil sa- 
car la ropa, pero su almacenamiento será menos compacto: tres cuartos de ca- 
da cajón estarán vacios. También será más difícil transportar toda la ropa de 
un lado a otro como conjunto. 

Unas consideraciones exactamente análogas se pueden aplicar a la compac- 
tación de datos dentro del ordenador. Cuando en PASCAL declaramos una 
matriz o un registro (véase más adelante), podemos darle el atributo packed 
o compactado. Con esto informamos al compilador de que estamos más inte- 
resados en la compacidad que en la velocidad de acceso a los elementos indivi- 
duales. El compilador puede hacer o no hacer caso de nuestra advertencia; ello 
dependerá en gran medida de las facilidades de compactación de datos de que 
disponga nuestro ordenador. En algunas máquinas el packed puede suponer 
ciertamente la diferencia entre poder o no poder meter los datos en la máqui- 
na, por caber o no caber en ella. 
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La única facilidad de lenguaje que se pierde con el packing o compactado 
es que no se puede usar un elemento individual de una matriz como parámetro 
var para una llamada a un procedimiento o a una función. Es perfectamente 
permisible pasar toda una matriz compactada, con tal que tanto el argumento 
como el parámetro se declaren como packed. Por consiguiente, podríamos ha- 
ber cambiado el precedente ejemplo de poneracero declarando a vectorl0 en 
esta forma: 


vector1l0 = packed array [1..10] of integer; 


y el programa seguiría siendo válido. Tres posibles líneas orientativas para el 
uso de la compactación son: 


e el máximo beneficio se consigue mediante la compactación de arrays 
o matrices de pequeños objetos, tales como datos char, datos Boo- 
lean, o pequeños subrangos de enteros o integers. En breve veremos 
que los caracteres compactados tienen una importancia especial en 
PASCAL; 


e si se accede frecuentemente al array o matriz como conjunto (por 
ejemplo, asignándola a otra matriz o pasándola como un parámetro 
no var), eso favorece el compactado, ya que los datos compactos son 
más fáciles de mover o transportar de un lado a otro; 


e  siaccedes frecuentemente a elementos individuales de la matriz, ello 
hace que tu compactado sea menos atractivo. 


Un método bueno e indoloro para evaluar la utilidad del packing o com- 
pactado en tu máquina, consiste en deslizar a hurtadillas unos cuantos packed 
en un programa de un amigo. Si, al día siguiente, te comenta orgullosamente 
lo mucho que ha conseguido mejorar el funcionamiento de su programa, ya 
sabes que el compactado es bueno, y entonces puedes probar a emplearlo en 
forma selectiva en tus propios programas. 

El PASCAL provee procedimientos incorporados, llamados pack y unpack, 
para copiar una matriz no compactada en otra que lo esté, y viceversa (véase 
el Apéndice A). 


Los strings o cadenas en BASIC 


Vamos a presentar ahora el tema de los datos en strings o cadenas. Las 
distintas implementaciones BASIC difieren grandemente en cuanto a las faci- 
lidades que ofrecen para el manejo de cadenas. Sin embargo, tienen una cosa 
en común: todas ellas son mejores que las del PASCAL. Resulta una especie 
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de impacto enterarse de que las facilidades de manipulación de cadenas que 
tiene el BASIC (aparentemente sencillas) aventajan bastante no sólo a las del 
PASCAL, sino también a las de la mayoría de los nuevos, brillantes y actualí- 
simos lenguajes estudiados por el profesor Primple y sus colegas. 

La mayoría de los BASIC soportan cadenas de longitud dinámica, es de- 
cir, cuya longitud puede variar desde cero hasta el tamaño admisible. Así, se 
puede decir 


LET S$ = “GETS” 
LET S$ = S$ £ “MAS LARGO” 


El operador **£”” concatena el valor anterior de S$ con MAS LARGO, ajus- 
tando así a S$ a la longitud de MAS LARGO. El resultado es que la longitud 
de S$ ha aumentado. Muchos BASIC, incluso en los microordenadores menos 
potentes, permiten que las cadenas varíen en longitud desde cero a 255 carac- 
teres. Tal vez nunca te hayas dado cuenta de que ésta es una característica de 
lujo. 


Los strings o cadenas en PASCAL 


En PASCAL, una variable de cadena se representa como una matriz com- 
pactada char. (Algunos BASIC adoptan un sistema parecido, y permiten que 
se acceda a las variables de cadena como si fuesen matrices de caracteres indi- 
viduales sencillos.) La matriz o cadena ha de tener como límite inferior el 1. 
El equivalente en PASCAL de las expresiones BASIC 


LET R$ = “sí” 
LET N$ = “Pedro” 
es 
var 
contestación: packed array [1..2] of char; 
nombre: packed array [1..5] of char; 
begin 
contestación: = “sf”; 
nombre: = “Pedro”; 


Al declarar las variables de cadena en esta forma, se obtienen todas las fa- 
cilidades normalmente con las matrices o arrays en PASCAL. Entonces se po- 
drá decir 

contestación[j]: = nombre[3]; 
para asignar el tercer carácter de nombre al jésimo carácter de contestación. 
Además, se consiguen tres facilidades adicionales que son exclusivas de las ca- 
denas O strings: 
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1) se puede asignar una constante de cadena a una variable de cadena; las 
dos últimas líneas del ejemplo introductorio son muestras de esto; 


2) se pueden aplicar operadores de relación a las variables y/o constantes de 
cadena oO string; 


3) se pueden sacar variables o constantes de cadena (pero, como veremos en 
el capítulo 9, no se pueden introducir más que carácter por carácter). 


Un ejemplo que ilustra los puntos 2) y 3) es 


if nombre <> “Bruce” then 
writeln(nombre, 'no es australiano”); 


En PASCAL, las variables de cadena son de tamaño estático, es decir, su 
longitud es siempre la misma que la del array o matriz en que estén almacena- 
das. Por tanto, contestación ha de tener siempre un valor de exactamente dos 
caracteres, y nombre ha de tenerlo de exactamente cinco caracteres. Por consi- 
guiente, no se puede decir 


nombre: = contestación; 


porque estaríamos tratando de dar a nombre un valor de dos caracteres. Simi- 
larmente, resulta que tanto Bill Mudd como el profesor Primple tienen razón 
cuando sentencian, desde sus puntos de vista diferentes, que no se puede com- 
parar al BASIC con el PASCAL. La expresión de relación 


BASIC” > “Pascal” 


nos dará un error con toda probabilidad, ya que las dos cadenas tienen longi- 
tudes diferentes. Si quitamos la **1'? de PASCAL, podríamos probar 


BASIC” > “Pasca” 


y, para disgusto de Bill, el resultado sería false porque el operador ** >”” utili- 
za el orden natural del diccionario. Lo mismo ocurriría si añadiéramos un es- 
pacio al final de BASIC. Por cierto que la relación 


“BASIC * > “pascal” 


daría resultados indefinidos porque, como hemos dicho anteriormente, los jue- 
gos de caracteres pueden variar entre sí respecto a si las letras mayúsculas van 
o no delante de las minúsculas. 

Como probablemente habrás notado ya, el Sindicato de Procesadores de 
Cadenas en PASCAL es todavía más fuerte que el Sindicato de Operadores 
de Constantes en PASCAL. Es tan fuerte, en efecto, que sus miembros apenas 
trabajan. Ciertamente, no podrás conseguir de ellos que rellenen una variable 
string o de cadena con espacios vacíos para completar la longitud exigida. Tal 


vez pudieras convencerles para que rellenen una constante de cadena con el 
número adecuado de espacios. Por ejemplo, podrían aceptar 


contestación: = “no”, 
como sustituto de 


contestación: = no ”; 


Consulta los detalles en tu manual PASCAL local, ya que hay algunos compi- 
ladores que ofrecen ampliaciones no incluidas en el Sindicato. 

Sin embargo, tendría que tratarse de un compilador muy ampliado o ex- 
tendido para que ofreciera facilidades tales como la concatenación, u opera- 
dores que extraigan subcadenas de cadenas, como el LEFTS, el RIGHTS y el 
SEG$ que se encuentran en algunos BASIC. Si existen, estas facilidades dan 
lugar a programas no portables, a menos que el PASCAL ampliado sea tan 
bueno que llegue a ser una norma de facto, cosa que ocurre algunas veces. La 
mayoría de los sistemas PASCAL no permiten ni siquiera definir una función 
que produzca un resultado en string o cadena, porque las funciones no pueden 
producir una cadena como resultado. 

Si anteriormente has considerado que las restricciones del PASCAL sobre 
las matrices eran una tragedia ocurrida en una tierra lejana, ahora, tras ver 
el impacto que ello tiene sobre las cadenas o strings, pensarás que la tragedia 
se ha producido un poco más cerca de lo que creías. 

El mismo profesor Primple ha encontrado algunos problemas en relación 
con las restricciones que el PASCAL impone en las cadenas. 


“Mi programa para analizar oraciones inglesas funciona bien”, dijo, 
insistiendo en un tema familiar, ““pero tiene una pequeña restricción, 
en cuanto que obliga a que todas las oraciones contengan diez palabras, 
y cada palabra ha de ser de cinco letras.”” 


Los comentarios de Bill Mudd acerca de este aspecto del PASCAL no pue- 
den compactarse en una cadena de longitud fija. 


Superando las restricciones 


Si al llegar aquí estás desesperado, tal vez te anime el saber que es posible 
burlar la intransigencia del Sindicato construyéndose uno sus propias cadenas 
O strings de longitud dinámica. Así que, en realidad, al profesor Primple le 
habría sido posible evitar las pequeñas restricciones de su programa. 
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Las cadenas o strings de longitud dinámica se pueden conseguir, por ejem- 
plo, asociando dos variables con cada una de nuestras cadenas: una, un entero 
o integer que da su longitud actual, y la otra variable de cadena PASCAL cu- 
ya longitud sea la longitud máxima de nuestra cadena. Entonces uno puede 
escribir procedimientos para manipular estas cadenas o strings. Estos procedi- 
mientos sólo procesan los caracteres hasta la longitud actual; de los caracteres 
siguientes se hace caso omiso, aun cuando estén presentes. (Si quieres hacerte 
una idea de esta técnica, echa un vistazo a la pág. 168.) Cada cadena que se 
pase a estos procedimientos, se representa como un par de argumentos, que 
dan las dos variables asociadas con la cadena. Podríamos tener un procedi- 
miento 


assign(longitudl, cadenal, longitud2, cadena2); 


que asigna una cadena a otra. Podría utilizarse este procedimiento en lugar 
de las facilidades incorporadas del PASCAL para la asignación de cadenas, 
y podrían escribirse procedimientos similares que tomaran el puesto de las res- 
tantes facilidades del PASCAL. 

El resultado global de tus esfuerzos no sería bonito, y las constantes de ca- 
dena seguirían siendo un tedioso problema, pero por lo menos podrías rehuir 
las restricciones del Sindicato. El uso de registros, que se describe en el ca- 
pítulo siguiente, te permite representar cada una de tus cadenas como un solo 
registro, en lugar del par de cantidades arriba descrito; esto contribuye a la 
concisión del programa. 

Existen, como alternativa, algunas propuestas en la literatura concerniente 
a las cadenas o strings en PASCAL; véanse Bishop (1979) y Sale (1979). Estos 
representan las cadenas o strings como archivos (files), y tienes que hacer co- 
sas raras, como rebobinar las cadenas antes de utilizarlas de nuevo. Sin em- 
bargo, cuando uno está desesperado no puede ser demasiado exigente o espe- 
cial sobre el uso de argucias raras. 


El registro de mi historial habla por sí mismo. 


Afirmación popular 


Registros 


La declaración de un registro 


El personal dedicado al aspecto comercial de los ordenadores ha venido 
utilizando el concepto de un registro desde finales de la década de los cincuen- 
ta. (N. del T.: Otra vez se divierte el autor en un juego de palabras, usando 
la palabra ““record”” en su doble sentido, como “*registro”” y como “marca ba- 
tida””.) El resto de la gente ha necesitado bastante tiempo para ponerse a su 
altura, y el PASCAL es uno de los primeros lenguajes que han popularizado 
los registros en campos más amplios. 

Se utiliza un registro (record) para construir un nuevo tipo de datos que 
esté formado por una colección de otros tipos de datos (que pueden ser, y usual- 
mente lo son, distintos entre sí). 

El ejemplo siguiente muestra la forma en que se declaran y se usan los 
registros. 
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type 
solicitante = 
record 
peso: 1..30; (* peso en stones, medida inglesa equivalente a 
14 libras x) 
edad: 0..150; 
legustaelPascal: Boolean («+ Primple dice que se omita este 
punto y coma »x); 
end; 
var 
Primple: solicitante; 
Mudd: solicitante; 
solicitanteactual: solicitante; 


Aquí el registro solicitante consta de tres campos: la edad y el peso del soli- 
citante, y la Booleana /legustaelPascal, que es verdadera o true si al solici- 
tante le gusta el PASCAL. (Para beneficio de los lectores formados en esos 
países que no utilizan unidades tales como cadenas, varas, pértigas y perchas, 
y que probablemente tampoco juegan al cricket, diremos que nuestra unidad 
de peso es un stone (o piedra). Un stone es catorce libras. Una libra es, desde 
luego, el peso de un décimo de un galón imperial de agua. Un galón es...) 

La única operación que se puede realizar con una variable que es un regis- 
tro es asignarla a otra variable, que haya sido declarada como un registro idén- 
tico. Así, podemos decir 


solicitanteactual: = Primple; 
o, esforzando mucho la imaginación, 
Primple: = Mudd, 


No existen constantes del tipo registro o record, del mismo modo que no las 
hay del tipo matriz (si se exceptúan las cadenas o strings). 


Tipos estructurados 
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Tanto los registros o records como las matrices o arrays se llaman en PAS- 
CAL tipos estructurados, y tienen muchas cualidades comunes. Acabamos de 
ver que no es mucho lo que se puede hacer con los registros como conjunto, 
lo mismo que tampoco se puede hacer con las matrices o arrays. En lugar de 
ello, la mayoría de las operaciones se realizan sobre sus elementos individua- 
les. A los elementos de las matrices accedemos por medio de subíndices; en 
cambio, a los campos de los registros accedemos por medio de los identifica- 


dores de campo. Los identificadores de campo son los nombres que se escri- 
ben delante de los componentes del registro, es decir, en nuestro ejemplo, pe- 
so, edad y legustaelPascal. Desde luego, en un solo registro no puede haber 
dos campos con el mismo nombre, por ejemplo, dos edades. Sin embargo, si 
que se puede usar el mismo identificador de campo en dos registros separados. 
De este modo, pueden tener el campo edad otros registros, además del de soli- 
citantes. 

Cuando queremos acceder a un campo de un registro, escribimos un punto 
después del nombre de la variable del registro, y a continuación el identifica- 
dor de campo, por ejemplo: 


Primple.edad: = 45; 
Mudd. legustaelPascal: = false; 
if cumpleaños then 
Primple.edad: = Primple.edad + 1; 


Como ejemplo adicional, la sentencia de asignación 


solicitanteactual: = Mudd, 
equivale exactamente a 


solicitanteactual.peso: = Mudd. peso; 
solicitanteactual.edad: = Mudd.edad, 
solicitanteactual.legustaelPascal: = Mudd.legustaelPascal; 


Puede verse que la notación para acceder a los campos de los registros es 
ligeramente diferente de la empleada para acceder a los elementos de matrices, 
a saber: 


variableregistro.campo en lugar de  variabledematriz[subíndice] 


Esta diferencia es razonable; deja ver claramente a un lector del programa si 
se está accediendo a un registro o a una matriz. No hace falta consultar la de- 
claración. 

Al igual que los elementos de matrices, los campos de los registros pueden 
utilizarse como variables ordinarias. Igualmente, como las matrices o arrays, 
los registros pueden ser compactados (packed), con ventajas potenciales simi- 
lares. 


Estructuración de datos 


Es posible que hayas notado cierta semejanza entre el begin y el end em- 
pleados para agrupar sentencias, y el record y el end usados para agrupar da- 
tos. Esto nos da la clave del uso fundamental de los registros: ayudar a la 
Sra. Buzz a dar una estructura a los datos, lo mismo que el begin y el end (en 
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unión de otras construcciones) le ayudan a dar una estructura a las sentencias 
dentro de un programa. Ambas cosas son igualmente importantes. El título 
de la obra de Wirth Algoritmos + estructuras de datos = programas (1976) lo 
dice todo. 

De la misma manera que se pueden anidar begin y end, podemos anidar 
registros. Para demostrarlo, vamos a modificar nuestro registro de solicitan- 
tes de modo que contenga un campo de fecha de nacimiento en lugar de un 
registro de edad. Algunos posibles patronos piden en sus impresos de solicitud 
de empleo los dos datos, edad y fecha de nacimiento, y eliminan a aquellos 
solicitantes cuya edad no concuerda con su fecha de nacimiento; se dice que 
los licenciados en informática son de los que más suelen fallar en esta prueba. 
Como no queremos ser demasiado duros con los licenciados en informática, 
prescindiremos del campo redundante de la edad. La fecha de nacimiento cons- 
tituirá por sí sola un registro, formado por un día, un mes y un año. Entonces 
podremos declarar nuestro registro modificado en esta forma: 


type 
solicitantea = 
record 
peso: 1..30; 
fechanacimiento: 
record 
día: 1..31; 
mes: (Ene, Feb, Mar, Abr, May, Jun, Jul, Ago, Sep, 
Oct, Nov, Dic); 
año: 1850..2000; 
end; 
legustaelPascal: Boolean; 
end; 


Lo mismo podríamos haber escrito lo que antecede en esta forma: 


type 
fecha = 
record 
día: 1..31; 
mes: (Ene, Feb, Mar, Abr, May, Jun, Jul, Ago, Sep, Oct, Nov, 
Dic); 
año: 1850..2000; 
end; 
solicitanteb = 
record 
peso: 1..30; 


fechanacimiento: fecha, 
legustaelPascal: Boolean; 
end; 


La ventaja de los registros anidados debe ser evidente, ya que son análogos 
a otras estructuras anidadas. Su ventaja consiste en que es posible tratar como 
una unidad a un subregistro, como fechanacimiento, incluido dentro de un re- 
gistro más grande. 

Para acceder a un campo que se halle anidado a n niveles de profundidad 
en un registro, deben especificarse todos los n identificadores de campo que 
son necesarios para ““hallar”” el campo, comenzando por el registro más exter- 
no, por ejemplo: 


Primple. fechanacimiento.mes: = Feb; 


El ejemplo precedente es aplicable independientemente de si el registro ha 
sido declarado en la forma usada para solicitantea o en la de solicitanteb. Los 
identificadores de campos de los registros internos no han de ser iguales que 
los de los externos, pero, a pesar de ello, seguimos estando obligados a escribir 
todos los n identificadores. 


Facilidades para el anidamiento 


Hace algunos años, una emotiva frase publicitaria que trataba de animar 
a los británicos para que emigrasen a Australia, decía ““En Australia, puedes”. 
(El anuncio no registraba las frases correspondientes que podrían circular dentro 
de Australia, diciendo lo que podían hacer los británicos.) 

Si deseas adoptar el estilo de programación de Bill, un eslogan equivalente 
a éste y relativo al PASCAL podría ser: “En PASCAL, no puedes”. Ya co- 
mentamos, en el capítulo 2, la disciplina que el PASCAL impone. 

A pesar de todo, existe un ámbito en el que el eslogan es, decididamente, 
“En PASCAL, puedes””. Este ámbito es el del anidamiento. Efectivamente, 
casi siempre, y en forma invariable, está permitido llevar el anidamiento hasta 
cualquier profundidad que uno pueda razonablemente desear, y se puede ani- 
dar cualquier cosa dentro de cualquier otra. Por tanto, si preguntas si una fa- 
cilidad x está permitida dentro de un registro, la respuesta será afirmativa. En 
consecuencia, podemos tener matrices de registros, o registros que contengan 
matrices, Oo podemos combinar ambas cosas como en el ejemplo que sigue: 


array26 = array [2..6] of real; 
profnido = array [1..5] of 
record 
a: array26; 
b: array [3..7] of 
record 
c: real, 
d: array ['a”..“e”] of Boolean; 
end; 
Zz: integer; 
end; 
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A tal estructura se podría acceder en la forma siguiente: 


var 
x: profnido; 
yarray: array26; 

begin 

(E 


. *) 

x[11.0[3].d[*c*]: = true; 

yarray: = x[2].a; (x* referencia a una matriz completa dentro de un 
registro +) 


. y 


Una opinión alternativa 


“Bueno, todo este rollo sobre la estructuración está muy bien””, dijo 
Bill, “pero, ¿para qué sirven estos registros? Todo lo que puedes hacer 
con ellos es asignarlos a otros registros. Me parece que son un caso más 
de acumulación de morralla redundante en los programas.”” 


Bill está escribiendo también un libro. Lo titula 4/ BASIC desde el PAS- 
CAL. Espera que sea el mayor éxito de ventas de todos los tiempos, y fue tan 
amable que nos enseñó un primer borrador. En la primera página aparece este 
conmovedor consejo: 


“¿Tienes problemas para recordar todos los tipos de datos del PAS- 
CAL? ¿Tropiezas con dificultades para decidir cuál de ellos usar? ¿Te 
preocupa que furtivos espías académicos puedan leer tus declaraciones?”” 

““Olvídate de todo ello. El mundo está formado solamente de núme- 
ros y de cadenas, además de matrices de cualquiera de ellos. Cualquier 
problema real se puede reducir siempre a estos tipos de datos, con tal 
que le des vueltas durante el tiempo suficiente. No te preocupes tampo- 
co por los espías furtivos; lo más probable es que nadie más que tú sea 
capaz de averiguar lo que hacen tus variables, así que nadie te podrá 
criticar.?” 


Un ejemplo 


Sean cuales sean los méritos de los argumentos de Bill, es indudable que 
subestima bastante la utilidad de los registros **que sólo pueden asignarse a 
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otros registros””. Esto es porque un ejemplo de asignación está siendo utiliza- 
do como un argumento. Por tanto, puedes escribir procedimientos y funcio- 
nes para manipular los registros que has definido. 

Tomemos como ejemplo el registro 


complejo = 
record 
partereal: real; 
imaginaria: real, 
end; 


Este registro define un número complejo, que es un concepto muy utilizado 
en matemáticas e ingeniería y, por consiguiente, en los programas de ordena- 
dor. Los números complejos fueron inventados, con este mismo nombre, hace 
mucho tiempo. De haberse inventado ahora, y de acuerdo con algunas obser- 
vaciones que ya hemos expresado, los encargados de las relaciones públicas 
les habrían dado el nombre de “números sencillos””, o algo así, para distin- 
guirlos de los números *“*muy sencillos”” corrientes. 

Para aquellos que nunca hayan tropezado con los números complejos o 
que, felizmente, los hayan olvidado, explicaremos que un número complejo 
es un par de números, a uno de los cuales se le llama la parte real, mientras 
que al otro se le conoce como la parte ¡maginaria. 

Existe un conjunto de reglas para definir las operaciones aritméticas con 
números complejos. A continuación se muestran dos reglas: la notación (x, y) 
significa un número complejo con parte real x e imaginaria y: 


Suma: (a,b) + (c,d) = (a+b, c+d) 
Multiplicación: (a,b) x* (c,d) = (ac—bd, bc + ad) 


Dadas estas reglas, podrías pensar que sería fácil escribir un juego de fun- 
ciones PASCAL para realizar aritmética de complejos. Sin embargo, ello no 
es posible, porque el resultado de una función PASCAL ha de ser un tipo de 
datos sencillo, mientras que nuestras necesidades demandan funciones que pro- 
ducen como resultado números (es decir, registros) complejos. De aquí que 
tengamos que formular las operaciones como procedimientos, y no como fun- 
ciones. 

Nuestro procedimiento para realizar sumas de complejos es: 


procedure sumcomplej (var x: complejo; y, z: complejos); 
(* Esto hace x:= y + z; en donde x, y y z son números complejos +) 
begin 
x.partereal: = y.partereal + z.partereal; 
x.imaginaria: = y.imaginaria + z.imaginaria; 
end; (x* sumcomplej x) 
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Un procedimiento similar para hacer las multiplicaciones es: 


procedure multcomplej (var x: complejo; y, z: complejos); 
(* Esto hace a x:= y x z; en donde x, y y z son números complejos x) 
begin 
x.partereal: = y.partereal x z. partereal — y. imaginaria « z. imaginaria; 
x.imaginaria: = y.imaginaria x z. partereal + y.partereal x z.imaginaria; 
end; (* multcomplej x) 


Dados estos procedimientos, una operación compleja tal como 
cl:= (2 + (3 x c4; 
se puede programar como 


multcomplej(temp, c3, c4); 
sumcomplej(cl, c2, temp); 


en donde temp es una variable de tipo complejo. 

Estos procedimientos recuerdan algo las rutinas MAT que se encuentran 
en algunos BASIC. La única diferencia es que aquí nosotros hemos definido 
nuestras propias operaciones; no tenemos que depender de que estén incorpo- 
radas en el lenguaje. (Podríamos haber definido nuestros propios equivalentes 
exactos de las sentencias MAT si el PASCAL permitiese usar como argumen- 
tos matrices o arrays de tamaño variable.) 

Como forma alternativa para la escritura de nuestros procedimientos arit- 
méticos para complejos, podríamos haber definido, en el programa principal, 
una variable compleja llamada acumulador, y haber revisado nuestros proce- 
dimientos para que dejaran el resultado de sus operaciones en este acumula- 
dor. Entonces los procedimientos no necesitarían el argumento x, y el estilo 
de programación se haría similar al de un lenguaje ensamblador típico (el len- 
guaje de bajo nivel para una máquina determinada), por ejemplo: 


multcomplej(c3, c4); 
sumcomplej (c2, acumulador); (« ahora el resultado está en el acumulador +) 


Abstracciones 


Nuestro ejemplo de los números complejos nos muestra un estilo de pro- 
gramación muy productivo. Lo que hacemos es definir nuestro propio tipo de 
datos, complejo, más un juego de procedimientos para trabajar sobre ese tipo 
de datos. Lo conseguido finalmente es casi tan bueno como si los complejos 
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hubieran estado incorporados en el PASCAL ya para empezar; la única som- 
bra que lo empaña es que la sintaxis para el uso de nuestros procedimientos 
es bastante desmañada, aunque sin serlo de un modo intolerable. 

Lo que hemos creado es una abstracción de datos. Se trata de una abstrac- 
ción alejada de los tipos de datos incorporados en el PASCAL, y enfocada 
al problema que se está resolviendo. El PASCAL, aunque esté lejos de ser la 
herramienta perfecta, es una ayuda para conseguir esto. Obsérvese cómo los 
detalles referentes a la forma de realizar aritmética de complejos quedan con- 
finados al interior de nuestros procedimientos. Por tanto, el programa princi- 
pal queda libre de estos detalles de bajo nivel y, como resultado de ello, más 
fácil de entender. Esto es un ejemplo de ocultamiento de información. 

El profesor Primple, cuyo nombre está muy asociado con la abstracción, 
cree que ésta es la más importante de las ayudas de programación. 

Comprueba la validez de esta opinión suya haciendo algunas abstracciones 
por tu cuenta. Siempre que en un programa tengas una o más variables rela- 
cionadas entre sí (como una pila o stack y el indicador o puntero de la parte 
superior de la misma), agrupa estas variables formando un registro. Luego de- 
fine algunos procedimientos y, si ello es apropiado, funciones para manipular 
los registros. ¿No se hace más fácil la programación? Lo que es más importan- 
te, ¿no es más fácil la lectura de tu programa? ¿No puede el lector, por ejem- 
plo, separar fácilmente los conceptos generales de los detalles, y contemplar 
aisladamente los unos y los otros? 


La sentencia with (con) 


Volvamos a nuestros solicitantes, que llevan ya demasiado tiempo espe- 
rando. 

Nuestra tarea consiste en escribir una función evaluación, que evalúa a los 
solicitantes de un determinado trabajo de programación. El que sea nombra- 
do tiene que compartir una terminal, de modo que el solicitante ha de pesar 
lo suficiente para poder echar a otro a empujones. La función evaluación pro- 
duce una puntuación que califica la adecuación del aspirante; cuanto más alta 
sea la puntuación, mejor. La función es como sigue: 


function evaluación (persona: solicitante): integer; 
(x* evalúa la adecuación del solicitante de un trabajo «) 
var 
puntuación: integer; 
begin 
puntuación: = persona.peso; («* un punto por cada stone de peso x) 
if persona.legustaelPascal then 
puntuación: = puntuación + 50; 
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if (persona.edad > 25) and (persona.edad < 45) then 
puntuación: = puntuación + 20; 
evaluación: = puntuación; 
end; (* evaluación +) 


(Perkins dice, con bastante razón, que esta función se podría mejorar definiendo 
un tipo subrango y usándolo en lugar de integer cada vez que éste se produce.) 
A esta función se la puede llamar por código o clave, como 


if evaluación(Primple) > evaluación(Mudd) then 
write( “Primple”) 

else 
write(*Mudd”); 

writeln(* consigue el trabajo”)y; 


Al codificar la función evaluación, fue bastante aburrido tener que escribir 
““persona”” numerosas veces. Para ahorrar este aburrimiento, el PASCAL pro- 
porciona una especie de notación taquigráfica mediante la cual se puede decir 
“Dentro de este contexto, todos los campos se refieren a la variable de registro 
x'”. Esto se hace por medio de la sentencia with (con), que tiene una sintaxis 
(aunque no un significado) similar o parecida a la de la sentencia while (mien- 
tras). Usando with, la parte ejecutable de evaluación se puede escribir de nue- 
vo en esta forma: 


begin 
with persona do 
begin 
puntuación:= peso; (x* un punto por cada stone de peso x) 
if legustaelPascal then 
puntuación: = puntuación + 50; 
if (edad > 25) and (edad < 45) then 
puntuación: = puntuación + 20; 
end; (* ámbito de with x*) 
evaluación: = puntuación; 
end; (* evaluación x) 


De modo análogo, la parte ejecutable de sumcomplej se puede escribir 


begin 
with x do 
begin 
partereal: = y.partereal + z.partereal; 
imaginaria: = y.imaginaria + z.imaginaria; 
end; 
end; (x* sumcomplej x) 


aunque aquí el beneficio obtenido con el uso de with es marginal en el mejor 
de los casos. El ejemplo muestra, sin embargo, que dentro de with puede ha- 
cerse referencia a registros que no son el tema de with. 

Existen formas más elaboradas de with que tú puedes probar cuando te ha- 
yas acostumbrado ya al caso sencillo. Y, desde luego, se pueden hacer anida- 
mientos con with. Para detalles, consúltese el informe del PASCAL. No se ol- 
vide, sin embargo, que la idea de un with es hacer que el programa sea más 
fácil de leer y de escribir, de modo que uno complicado destruye su propia 
finalidad. 

Recuérdense dos puntos en relación con el with. En primer lugar, se puede 
usar donde se quiera; su uso no está limitado a los procedimientos. En segun- 
do lugar, se trata sencillamente de una especie de notación taquigráfica; no 
implica formación de bucles, ni nada parecido. 

Efectivamente, un registro no lleva asociada ninguna facilidad para la for- 
mación de bucles. Esto contrasta con lo que ocurre con las matrices o arrays, 
en las que se puede hacer uso de una sentencia for para trazar bucles entre 
los elementos. Si lo piensas, te darás cuenta de que el realizar la misma opera- 
ción en cada campo de un registro casi nunca es una cosa sensata, porque los 
campos son generalmente de tipos de datos distintos. 

Dada la falta de un concepto de repetición en bucle, el orden de escritura 
de los campos de un registro es completamente el que uno quiera (excepto pa- 
ra los campos “variantes”? que se describen en la próxima sección). Podría- 
mos, por ejemplo, intercambiar el orden de edad y peso sin que ello afectase 
en absoluto a nuestros programas. 


Registros con variantes 


Uno de los problemas que presenta la programación en el mundo real es 
que los objetos no son uniformes. Así, si un registro de un programa describe 
a una persona, tenemos que una persona casada tiene un cónyuge, mientras 
que una soltera no lo tiene. Si la persona trabaja en una compañía y percibe 
un sueldo, los datos requeridos son diferentes de los de un jornalero; si la per- 
sona es extranjera, sus datos relativos a los impuestos serán diferentes. 

Para tener todo esto en cuenta, el PASCAL permite que un registro con- 
tenga un campo de variantes, que ha de venir al final de aquél. El campo de 
variantes puede adoptar distintas formas, dependiendo de algún criterio espe- 
cificado. Sin embargo, date por advertido: hasta al más fino y experimentado 
de los “relaciones públicas”” le resultaría difícil convencerte de que la impre- 
sión inicial que produce esta característica no es excesivamente complicada. 
Por consiguiente, aprieta los dientes antes de pasar a lo que sigue. 

Vamos a utilizar como ejemplo la existencia de piezas de repuesto en un 
almacén. Estas piezas encajan en dos categorías: algunas poseen un número 
entero, conocido como el “número de pieza””, por el cual se las representa, 
en unión de una “clave o código de clase””, que informa sobre la fortaleza de 
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la pieza, expresándola como robusta, normal o delicada; los componentes que 
no poseen número de pieza se representan por medio de una cadena de diez 
caracteres, que hace el oficio de “'nombre de pieza”. 

El registro con variantes lleva asociado un campo discriminador (discrimi- 
nator) para decir cuál de las posibilidades se ha de aplicar. En nuestro caso, 
el discriminador puede ser un Boolean, porque sólo hay dos posibilidades. Lo 
hemos llamado fienenúmero. La declaración del registro es: 


type 
fortaleza = (robusta, normal, delicada); 
nombredepieza = packed array [1..10] of char; 


pieza = 
record 
coste: integer; 
(€ 
. kx) 
case tienenúmero: Boolean of 
true: ( 
númeropieza: integer; 
códigoclase: fortaleza 
); 
false: ( 
nombrepieza: nombredepieza 
); 
end; 


Esta sintaxis, un tanto complicada, dice lo que más arriba hemos tratado 
de explicar en palabras. En detalle, dice que el último campo tiene varios casos 
(case) posibles. Puede argumentarse que el uso que el PASCAL hace aquí de 
la palabra case es una equivocación, ya que la sintaxis no es enteramente igual 
que la de la sentencia case descrita en el capítulo 4. (Sin embargo, vuestro com- 
pilador, que no olvida nada, espera a pesar de todo la palabra case.) La pala- 
bra case va seguida de una declaración del campo discriminador que se utiliza- 
rá para seleccionar la variante. En el cuerpo de case, cada valor posible del 
discriminador va seguido por una lista (que puede ser vacía) de declaraciones 
de campos, encerrada entre paréntesis. Estas declaraciones de campos se escri- 
ben en la forma normal. Como en una lista de parámetros, no se escribe punto 
y coma después de la última declaración de la lista. Puede confundirnos un 
tanto el hecho de que case no lleve asociado un end. En lugar de ello, y dado 
que el campo de variantes siempre viene al final del registro, el end de éste 
sirve también para finalizar el case. Los campos que hemos declarado en el 
case anterior se pueden usar exactamente igual que si se hubieran declarado 


tienenúmero: Boolean; 
númeropieza: integer; 
códigoclase: fortaleza; 
nombrepieza: nombredepieza, 


La única condición es, desde luego, que no se ha de intentar hacer referen- 
cia a un campo que no exista, como el nombrepieza de un componente para 
el que tienenúmero sea true. 

A fin de evitar tales catástrofes, normalmente se usa una sentencia if o case 
para averiguar qué variante está presente. Por ejemplo: 


var 
orden: pieza; 

begin 

(x 


*) 
if orden.tienenúmero then 
if orden.códigoclase = delicada then 
writeln(*Cuidado: es delicada”); 


Si escribimos, sin darnos cuenta, 


if orden.tienenúmero then 
write (orden.nombrepieza); 


o incluso sólo 
write (orden.nombrepieza); 


en un caso en el que tal campo es inexistente, el Admirable Perkins deberá ca- 
zarnos, ya que el campo nombrepieza no estará allí. Como siempre (o, por 
lo menos, casi siempre), aquí las actividades de Perkins son una gran ayuda 
para nosotros, porque impiden que los programas hagan disparates. (Sin em- 
bargo, es posible que tu compilador no haga la necesaria comprobación, en 
cuyo caso se perderá esta ventaja.) 


Ventajas de las variantes 


La ventaja más obvia de los registros con variantes es que economizan es- 
pacio de almacenamiento o memoria. Hay también otros dos aspectos igual- 
mente importantes. El de la seguridad, ya mencionado, que impide que se ha- 
ga referencia a campos inexistentes. Y también la cuestión de legibilidad, una 
vez que uno se ha acostumbrado a ellos: la descripción del registro facilita bas- 
tante información acerca de la forma en que el mismo está estructurado. 

La restricción que exige que la parte variante de un registro venga al final 
del mismo, no es ninguna restricción en realidad. Esto es porque las variantes 
(naturalmente) pueden anidarse, de modo que podamos introducir varias va- 
riantes en un registro, si puedes tolerar la idea. 
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Una forma alternativa de las variantes 


Finalmente, existe una forma alternativa para escribir las variantes, que de- 
berá servir de recompensa a Bill Mudd, si nuestro amigo ha conseguido llegar 
hasta aquí. Esta alternativa nos permite omitir el campo discriminador, con 
el resultado de que el Admirable Perkins no podrá vigilar lo que hacemos. Se 
llama una “unión indiscriminada””. Por ejemplo, podríamos decir que un campo 
es un número real, o un entero (integer) o una cadena de cuatro caracteres, 
y Bill podría establecer el campo, por ejemplo, como una cadena de caracteres 
y luego recuperarlo como entero o integer, sin que Perkins se entere. Si estás 
acostumbrado a programar en uno de los lenguajes llamados “sin tipos””, co- 
mo el BCPL (Richards € Whitby-Strevens, 1979), o incluso en lenguaje en- 
samblador, podrías apreciar las uniones indiscriminadas. Podrías definir un 
registro formado por un solo campo consistente en la unión indiscriminada 
de todos los tipos de datos que ocupen una sola palabra de tu máquina; esto 
te da el equivalente de una variable sin tipo. 

Una matriz o array de estos registros es como la memoria de una máquina. 
La sintaxis es: 


type 

(* Utilización típica de una palabra en un ordenador de 32 bits x) 
Cuatrocasos = 1..4 
palabra = 


record 
case cuatrocasos of 
l:( 


r: real 


i: integer 


str: packed array [1..4] of char 


B: Boolean 
»; 
end; 

store = array [1..1000] of palabra, 
var 

w: palabra; 
begin 

w.str:= “abed”; 

wrinteln(*Mi compilador almacena abcd como el número entero”, w.i); 


Obsérvese que el discriminador que sigue a case no tiene nombre, es sim- 
plemente un tipo. 

Estas facilidades son útiles para los sucios trucos de programación que a 
Bill le gusta hacer, pero, aunque sea triste decirlo, casi todos tenemos que re- 
currir alguna vez a truquitos sucios para conseguir que nuestros programas se 
adapten a las coerciones del mundo real, o puedan interconectarse con los dis- 
positivos de dicho mundo. 

La elección de los números enteros 1, 2, 3 y 4 en el ejemplo precedente 
es completamente arbitraria, ya que en realidad nunca hemos establecido un 
discriminador. No obstante, si hemos de enumerar los casos, ésta es una se- 
cuencia natural que se puede emplear. 


Equivalencia de nombre 


Finalmente, vale la pena repetir un punto especializado, pero importante, 
que se expuso ya en el capítulo anterior. Algunos compiladores insisten en que, 
cuando se asigna una variable a otra, si las dos variables están declaradas se- 
paradamente, ambas han de tener un tipo de datos con un nombre idéntico. 
No es suficiente declarar que ambas son matrices o arrays del mismo tamaño, 
o registros con los mismos nombres de campos. (La única excepción se encuentra 
en los tipos simples, en los que es posible asignar tipos compatibles entre sí; 
por ejemplo, un subrango de, digamos, enteros o integer, se le puede asignar 
a un entero, y viceversa.) Esta estricta regla se conoce como equivalencia de 
nombre, y se aplica lo mismo a la asignación explícita que a la implícita de 
un argumento a un parámetro. (Véase un estudio más amplio en Welsh, Snee- 
ring 4% Hoare, 1981.) Si declaras todos tus tipos en la sección type del progra- 
ma, dándoles nombres al hacerlo, estarás seguro. Lo mejor es dar nombres 
incluso a los tipos de datos de los campos en el seno de los registros. Así, nues- 
tro solicitanteb está mejor que el solicitantea, porque el primero tiene un nom- 
bre (fecha) para el tipo de datos del campo fechanacimiento. Como resultado 
de ello, este campo puede ser asignado sin riesgo a cualquier otra variable del 
tipo fecha. 
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Ne 


Uno de los mayores placeres de la vida es la conversación. 


REV. SYDNEY SMITH 


Entrada y salida 


Frecuentemente se mantiene que la enseñanza moderna da una importancia 
excesiva a materias novedosas y de relumbrón a costa de otros conocimientos 
básicos. El PASCAL padece males parecidos. Es realmente fuerte en cuanto 
a estructuras de datos y cosas análogas, pero relativamente débil en lo que ata- 
ñe a los campos de la lectura, escritura y aritmética. Su aritmética carece de 
un operador para la elevación a potencias y (omisión que sienten mucho los 
programadores comerciales) de operaciones con decimales. Su lectura y su es- 
critura, es decir, su entrada y salida, parecen ideadas para favorecer la venta 
del libro PASCAL a partir del BASIC que prepara nuestro amigo Bill. No se 
trata tanto de que el sistema de entrada/salida del PASCAL disponga de po- 
cas facilidades como, simplemente, de que hay algunas cosas fundamentales 
que es difícil o imposible hacer. 


Categorías de archivos 


Probablemente hayas pasado por la experiencia de tratar de imprimir un 
archivo y obtener como resultado un galimatías o una jerga extraña. Esto pue- 
de ser porque el contenido del archivo sea también un galimatías, pero fre- 
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cuentemente es debido a que el archivo está en memoria en una forma interna 
binaria que no es directamente imprimible. 

Como sin duda sabes, la mayoría de los ordenadores almacenan los núme- 
ros en una codificación binaria interna que es diferente de la cadena de carac- 
teres (cifras, comas decimales, etc.) que nosotros empleamos para representar 
los números. En realidad, la codificación interna de objetos tales como los nú- 
meros reales es muy elaborada, y es preciso mucho tiempo de ordenador para 
hacer la conversión entre (por ejemplo) 2.397E-3 y la codificación binaria 
equivalente. 

De aquí que, para economizar tiempo en la conversión, muchos ordenado- 
res tengan una facilidad para archivar información en una forma binaria que 
es, sobre poco más o menos, una imagen directa de la codificación contenida 
en la memoria o almacenamiento del ordenador. Estos son, entonces, los ar- 
chivos cuya impresión produce un galimatías. 

El PASCAL ofrece archivos de los dos tipos, de caracteres y binarios. Los 
primeros son los más corrientes, y se les conoce como archivos de texto O 
textfiles. 

En BASIC, cuando se hace referencia a un archivo, se utiliza un número 
de canal. Si se omite este número de canal, se utiliza el archivo de entrada o 
salida previsto en el sistema para tomarlo por defecto u omisión (default). Así, 
se puede usar 


PRINT X 


para imprimir usando el archivo de salida por defecto, o 


PRINT +3: X 


para imprimir usando el archivo correspondiente al canal 3. Y para las senten- 
cas INPUT se aplica un sistema equivalente. 

El PASCAL tiene una filosofía semejante en cierto modo, sólo que en ella 
se ha desterrado la influencia del Sr. 869704. Por consiguiente, los números 
de canales están sustituidos por identificadores, que se denominan variables 
de archivo o, más simplemente, archivos. Estos identificadores se declaran en 
la forma normal en la sección var del programa. Si se desea, pueden ser locales 
de un procedimiento, bien sea como parámetros o como variables locales. La 
sintaxis para las declaraciones de variables de archivos se ilustra en los ejem- 
plos que siguen: 


var 
Fl: file of char; 
$2: file of integer; 
$3: text; (* véase la explicación más adelante x) 


Un archivo es una secuencia o sucesión ordenada de componentes, todos 
los cuales son del mismo tipo de datos. Este tipo de datos se conoce como tipo 
de componentes, y puede ser cualquier cosa que uno quiera, aunque algunas 


implementaciones del PASCAL imponen ciertas restricciones a los archivos de 
archivos. 

Una declaración de archivo se parece algo a una de matriz, y más adelante 
volveremos sobre esta similitud. Si, como el fl anterior, un archivo es de ca- 
racteres (char), entonces se trata de un archivo de texto (textfile), es decir, la 
clase de archivo con el que estamos más familiarizados. Si el tipo asociado con 
el archivo es cualquier otro menos el char, se tratará de un archivo binario. 
Como quiera que los archivos de texto son los más frecuentes, el PASCAL 
tiene un tipo de datos incorporado denominado text, lo cual significa file of 
char. Así, el f3 precedente es, al igual que el fl, un archivo de texto. 

Los nombres input y output se consideran automáticamente como archi- 
vos de texto; corresponden a los archivos de entrada y salida por defecto, igual 
en gran medida que en el BASIC, y casi siempre corresponden a nuestra termi- 
nal. (Por consiguiente, el concepto de ““archivo”” se ha generalizado para in- 
cluir el material tecleado en la terminal, así como el material contenido en la 
memoria o almacén de reserva o de apoyo del ordenador. Los sistemas buenos 
ofrecen una completa independencia de dispositivos, como vimos en el ca- 
pítulo 3.) 

El uso de variables de archivo en las sentencias de entrada/salida se pare- 
ce también al uso de canales numéricos en el BASIC. Se puede escribir una 
variable de archivo como primer argumento opcional o facultativo en los pro- 
cedimientos read y write del PASCAL. Si se omite el argumento, se asumen 
read o write como sea apropiado. Así, las dos sentencias 


read(x, y); 
read(input, X, y); 


son equivalentes, como lo son estas otras dos: 


write(x, y + 6, pig”); 
write(output, x, y + 6, pig”); 


A continuación damos ejemplos del uso de las variables de archivo decla- 
radas más arriba: 


read(fl, X, y); 
read(f2, x, y); (+ también se pueden leer y escribir archivos binarios *) 


write(f3, Xx, y); 


Los tipos de datos en entrada/salida 


Si un archivo es de texto (textfile), se pueden leer de él elementos de datos 
de entrada que sean de los tipos integer, real o char. Los elementos de datos 
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numéricos contenidos en el archivo han de estar separados entre sí por uno 
o más espacios. (El BASIC utiliza normalmente como separadores comas, en 
lugar de espacios.) Alternativamente, los elementos de datos de entrada se pue- 
den poner en líneas separadas. Obviamente, cada elemento de datos ha de ser 
una constante del tipo apropiado. Si suministras los datos “*xyz”” cuando se 
necesite un número real, recibirás un aviso de error. Cuando se lee un número, 
se saltan todos los espacios y/o retornos de carro que le precedan, se toma 
el número, y se deja el archivo posicionado en el carácter que siga a dicho nú- 
mero. Cuando se lee un char, se toma un solo carácter, y un espacio cuenta 
como un carácter, al igual que cualquier otra cosa. 

Como ejemplo de formatos de datos, si el programa contiene las líneas 


var 

c: char, 

i: integer; 

r: real: 
begin 

read(c, i, r); 


la entrada de datos correspondiente puede ser 


x 23 9.7 


23 
9.7 


x23 
9.7 


o, finalmente 


x23 
9.7 


(Este último ejemplo muestra que no hace falta separador entre un carácter 
y un número.) 

Obsérvese que la sentencia read hace la conversión automática desde la for- 
ma externa (por ejemplo, 9.7) a la binaria interna. 

Para salida (output) a un archivo de texto, se pueden escribir (write) los 
mismos tipos de elementos que se pueden leer (read), es decir, char, integer 
o real. Hay, además, otros dos tipos de datos que se pueden escribir. La utili- 


zación en ficheros de los Boolean es la respuesta del PASCAL a la memoria 
write-only (de sólo escritura); se pueden escribir Booleanos —que salen o re- 
sultan como true o false—, pero no se pueden leer. Algo similar ocurre con 
las cadenas o strings, pero se puede escribir con bastante sencillez un procedi- 
miento para leer una cadena carácter por carácter. 

Para aquellos archivos que no sean de texto, sólo se pueden leer y escribir 
elementos de datos que sean del mismo tipo de datos que el tipo de componen- 
tes del archivo. 


Nombres de archivos externos 


Hasta ahora, no vamos mal; los archivos en PASCAL son en gran medida 
como probablemente esperabas que fueran. 

Los problemas empiezan cuando tratas de definir la correspondencia entre 
los nombres de archivo empleados en tu programa y los nombres reales de los 
archivos en tu sistema de archivo. Llamaremos a estos últimos archivos reales, 
o actual files, y a las variables de archivo correspondientes contenidas en tu 
programa, archivos externos, o external files (ya que se refieren a archivos 
que existen externamente al programa). Lo más probable es que los archivos 
reales se almacenen en un disco. 

En BASIC, la correspondencia entre los archivos reales y los externos (los 
números de canal del BASIC) se define por medio de una sentencia como 


FILE +3: “DATOS DEL ESTUDIO” 


En PASCAL no existe equivalente alguno a la sentencia FILE. En lugar 
de ello, hemos de especificar, en el encabezamiento del programa (es decir, en 
la construcción program, al principio mismo), todos los archivos externos que 
nuestro programa necesita. Esto explica por qué, para programas sencillos, es- 
cribimos como encabezamiento 


program x(input, output); 


Ello significa que los archivos input y output han de ser conocidos en el 
mundo exterior. Como mostramos en el capítulo 5, el encabezamiento de un 
programa es análogo en cierta forma al encabezamiento de un procedimiento. 
En el caso del encabezamiento del programa, todos los parámetros son nom- 
bres de archivos, y es por este medio como el programa interacciona con su 
entorno exterior. 

Antes de explicar otros archivos externos, concretaremos algunas cosas acer- 
ca del uso de input y output en los encabezamientos de programas. Hay algu- 
nos programas que, en realidad, no tienen ninguna entrada o input, y otros 
no toman ninguna entrada o input del archivo input por defecto. En estos ca- 
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sos, se puede omitir el parámetro input en el encabezamiento del programa. 
Es difícil imaginar un programa que no utilice output o salida alguna. Incluso 
un programa para copiar un archivo en otro, el cual no utilizaría output para 
su salida normal, todavía podría necesitar el output para posibles mensajes de 
error. De hecho, algunos sistemas PASCAL insisten en que se mencione output 
en el encabezamiento del programa. 


Correspondencia entre archivos externos y reales 
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Cuando tu programa emplee archivos externos distintos de los de input y 
output, éstos han de aparecer también en el encabezamiento. Por ejemplo, 


program análisis(input, output, fl); 


Para las reglas preferentes relativas a la ordenación de los nombres de es- 
tos archivos externos, consulta tu manual local; en ciertos sistemas, lo más con- 
veniente sería poner fl al principio de la lista. Algunos sistemas PASCAL per- 
miten poner un asterisco a continuación de los archivos que son para sólo lec- 
tura; esto constituye una protección contra la escritura accidental en ellos. Da- 
do el encabezamiento de programa que antecede, el nombre del archivo real 
que corresponde a fl viene definido entonces por la orden o comando de tu 
sistema operativo que inicie una ejecución (run) en PASCAL. Por ejemplo, 
podría ser 


RUN andlisis(,, DATOS DEL ESTUDIO) 


RUN análisis fl = DATOS DEL ESTUDIO 


(Algunos sistemas utilizan en lugar de “RUN” la palabra, más dramática, 
“EXECUTE”.) Los sistemas operativos varían mucho, de manera que ten- 
drás que consultar tu manual local. En la mayoría de los casos, lo que se em- 
pleará por defecto u omisión para input y output será tu terminal, pero puedes 
anular esta disposición si lo deseas. (En nuestros dos ejemplos de RUN, se han 
dejado sin especificar los archivos correspondientes a input y output. Esto sig- 
nifica que se aplicarán los correspondientes por defecto u omisión (default). 
Si en lugar de esto deseas que input y/o output vayan a otros sitios, puedes 
especificar los nombres de archivos reales.) 

En muchos sistemas operativos, la regla en los casos de defecto u omisión 
para archivos distintos de input y output es que el nombre real sea igual que 
el del archivo externo. En el ejemplo precedente, y en ausencia de una especifi- 


cación explícita, el nombre fl serviría también como nombre real. Sin embar- 
go, tales sistemas no son en modo alguno universales, y en general no se debe 
dar por supuesto que los nombres de los archivos externos se correspondan 
con los de los archivos reales (no más de lo que se corresponden con ellos los 
números de canal del BASIC). 

Todos los archivos externos, distintos de input y output, que especifiques 
en el encabezamiento del programa deberán declararse también en la sección 
var del programa principal. Así, si el encabezamiento es 


program xxx(input, output, fl, f2, 13); 


serían necesarias las declaraciones de fl, f2 y f3, como las dadas anteriormen- 
te en este capítulo. En cambio, los archivos input y output no han de ser decla- 
rados; ya están declarados por defecto. 

Dentro de tu programa PASCAL puedes crear algunos archivos tempora- 
les que no tengan existencia fuera del programa, o tal vez incluso fuera de un 
procedimiento del que el archivo sea local. Un ejemplo de esto podría surgir 
en un programa de ordenación o sorting, el cual crea un archivo intermedio 
que contiene una clase parcial de sus datos. No necesitas preocuparte acerca 
de nombres reales para estos archivos temporales. 

El problema que presenta el sistema PASCAL de nombres reales de archi- 
vo es que el número de archivos reales está determinado de antemano por el 
número de archivos externos incluidos en el encabezamiento del programa. Así, 
no es posible escribir (por ejemplo) un programa de fusión o intercalación (merg- 
ing) que lo haga con un número indeterminado o arbitrario de archivos. (Ni 
tampoco es posible escribir en PASCAL un intérprete de BASIC, si tu PASIC 
permite un número arbitrario de SAVE y OLD en diferentes archivos :eales.) 
Dada la severidad de esta restricción, algunos compiladores PASCAL tienen 
ampliaciones especiales para eludir el problema. Muchos amplían las senten- 
cias reset y rewrite, como describiremos más adelante. 


Características de los archivos en PASCAL 


En PASCAL, todos los archivos son secuenciales. No existe mecanismo al- 
guno para tener archivos de acceso aleatorio (random access), a menos que 
el compilador disponga de ampliaciones especiales. Esto significa que cuando 
leas un archivo has de empezar por el principio y progresar, componente por 
componente, a lo largo de él. Cuando escribes un archivo, lo único que puedes 
hacer es agregar cosas al final del mismo; no puedes cambiar nada que ya esté 
escrito, como no sea empezando otra vez desde cero y escribiendo de nuevo 
todo el archivo. 

Por tanto, asociado con todos los archivos hay un punto de exploración 
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o, en la terminología del PASCAL, una ventana que mira a un componente 
de un archivo (o al final de éste). Nos referimos a la ventana del archivo f co- 
mo f 1; su tipo de datos es el tipo de componentes del archivo, y se puede utili- 
zar como una variable ordinaria. El valor de f£ 1 es sinónimo del valor del com- 
ponente actual. 


Los procedimientos get y put 
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Si quieres realizar inputs y outputs con un nivel de detalle inferior al conse- 
guido con read y write, el PASCAL provee cierto número de procedimientos 
incorporados que pueden ocuparse de los archivos al nivel de ventana. Los más 
importantes de ellos son el gef, que se usa para lectura o entrada, y el put, 
que se usa para escritura o salida. 


La llamada 


get(f); 


hace avanzar la ventana del archivo f para que mire o apunte al componente 
siguiente de dicho archivo. 
El código o clave 


var 
ífile: file of t; (x* en donde t es cualquier tipo x) 
x: t; (x« una variable del tipo t x) 


begin 
x:= tfilel; 
get(tfile); 


lee en x el valor del componente actual, y hace que la ventana avance hasta 
después de éste. Esto es precisamente lo que hace el procedimiento read cuan- 
do se le llama con x como argumento. Por tanto, el código precedente equi- 
vale a 


read(tfile, x); 


Normalmente, todos los inputs se realizarán usando read, sin preocuparse 
del gef, pero a veces es conveniente programar a un nivel más bajo y utilizar 
las ventanas y el gef. Las mismas, o análogas, consideraciones, son de aplica- 
ción al write y a su procedimiento correspondiente de bajo nivel put. (Algunos 
compiladores siguen al informe del PASCAL en cuanto a restringir el uso de 
read y write a los archivos de texto o textfiles, aunque la norma PASCAL los 
permite para los archivos binarios. Si tienes un compilador tan restringido, ne- 


cesitarás rehacer los prohibidos read y write al nivel inferior; una tarea ligera- 
mente cansada, pero que no es onerosa. Esta tarea habría de hacerse, por ejem- 
plo, en el programa sumador de archivos que mostramos más adelante en este 
capítulo.) 

Obsérvese que, por lo que respecta a los archivos de texto, o textfiles, un 
read puede hacer más que un gef. Si leemos (read) un número real, por ejem- 
plo, el PASCAL toma (gets) automáticamente todos los caracteres que for- 
man el número, y los convierte a la forma binaria interna. 

Hay un procedimiento de salida (el put) que es el correspondiente al de entrda 
get. La llamada 


putf); 


añade la ventana f 1 al final del archivo f. Antes de hacer el put se debe asig- 
nar algo a la ventana. El archivo f ha de estar posicionado en el final de archi- 
vo antes de hacer el put. Esto es otra forma de decir que los archivos han de 
escribirse secuencialmente, que sólo se puede escribir en ellos agregando lo que 
sea al final. 


La sentencia 
write(tfile, Xx); 
es equivalente a 


tfileT:= x; 
putítfile); 


(Otra vez, sin embargo, los archivos de texto pueden ser una excepción. La es- 
critura, por ejemplo, de un número real en un archivo de texto es más compli- 
cada que un simple put, ya que implica una conversión y la salida (output) 
de varios caracteres.) 

El siguiente fragmento de programa ilustra el empleo de gef y put. Lee el 
archivo input hasta encontrar la primera vez que se produce el carácter “*:””; 
todo el texto sobre el cual se pasa, se copia al archivo output. 


while inputí < >“: do 

begin 
output!:=. input!; 
put(output); 
get(input); 

end; 


Tal como está, este programa tiene dos defectos, que explicaremos más ade- 
lante. Por tanto, nos referiremos de nuevo a este programa buscador del signo 
“dos puntos”. 
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Si deseas hacer algo ““cuestionable”?, como leer un archivo usando gef y 
luego escribir al final del mismo archivo usando put, consulta el manual de 
tu PASCAL local. Lo que puedas y no puedas hacer viene dictado más veces 
por el sistema operativo local que por las reglas propias del PASCAL. 


Inicialización de archivos 


El PASCAL provee un procedimiento incorporado 
rewrite(f); 


que prepara un archivo para la escritura; lo hace destruyendo el contenido an- 
terior del archivo (si lo tenía), y situando la ventana en el principio de aquél. 
En este caso, el principio del archivo es también su final, porque el archivo 
es nulo. 

Existe un procedimiento similar 


reset(f); 


que prepara un archivo para la lectura. Este sitúa la ventana en el principio 
del archivo, lista para la lectura. En este caso, el principio del archivo no es 
normalmente el final, o no habría nada que leer. 

Antes de usar cualquier archivo que hayas declarado, deberás hacer un re- 
set o rewrite del mismo, según corresponda. 

Sin embargo, los archivos incorporados input y output se preparan auto- 
máticamente para su lectura y su escritura (respectivamente), y nunca se debe- 
rán inicializar. 


“Todo muy lógico””, dijo Bill con cierto sarcasmo en la voz. “No 
entiendo por qué hacéis un rewrite a fin de prepararos para escribir, pe- 
ro no un reread cuando os preparáis para leer. El mismo nombre rewrite 
me parece también un poquitín extraño: “*re-escribís”? antes de ““escri- 
bir””. Indudablemente, si yo fuera tan inteligente como el profesor Prim- 
ple, entendería estas cosas.”” 


La función eof 


Frecuentemente se desea leer datos de entrada hasta que se terminan, es 
decir, hasta que se llega al final del archivo de entrada. En BASIC se puede 


164 


detectar el final de un archivo por medio de una sentencia tal como IF END. 
El PASCAL provee una función Booleana incorporada 


eof/) 


que es verdadera (true) sólo si el archivo f está posicionado al fin de un archi- 
vo. Por consiguiente, sólo se puede escribir (put o write) en un archivo si eof 
es verdadero (true), y sólo se puede leer de él (get o read) si eof es falso (false). 

Un defecto que tiene nuestro programa buscador de “dos puntos”” es que 
si no encontrara ningún signo de este tipo seguiría leyendo hasta pasarse del 
final del archivo. Sería mejor usar la función eof para comprobar esta condi- 
ción de error y, si surgiera, producir un mensaje de error. 

El programa completo que sigue ilustra el uso de los archivos y el eof. El 
programa suma una serie de números reales que hay en el archivo de entrada; 
cuando se llega al final del archivo, el programa imprime la suma total y se para. 


program sumarchivo(datafile, output); 
(* Programa para sumar todos los componentes de un archivo x) 


var 
datafile: file of real; 
sum: real; 
x: real; 
begin 
reset(datafile); 
sum:= 0; 
while not eofídatafile) do 
begin 
read(datafile, x); 
sum:= sum + X; 
end; 
writeln(*Sum= >", sum); 
end. 


Este ejemplo ilustra varios puntos que hemos hecho notar antes. Muestra 
cónio un archivo externo, tal como datafile, que aparece en el encabezamiento 
del programa, tiene que ser declarado entre todas las demás variables al co- 
mienzo del mismo. El archivo output, en cambio, no se declara. 

Este programa no usa el archivo input, que, por consiguiente, se ha omiti- 
do en el encabezamiento. Sin embargo, no habría importado que se hubiera 
incluido redundantemente en él. Muchas personas escriben siempre 


program xxx(input, output); 


como primera línea en todos sus programas (siempre que no utilicen archivos 
externos), independientemente de si en realidad se usa input. 
El archivo datafile se declara como un archivo de números reales. El pro- 
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grama podría ajustarse para trabajar sobre un archivo de texto (textfile) en 
lugar de uno binario, declarando el archivo de datos como 


datafile: text; 


Existen, sin embargo, problemas en el uso de eof en archivos de texto. Más 
adelante, en este mismo capítulo, definiremos una función texteof, que deberá 
usarse en lugar de la eof del programa precedente si su entrada es desde un 
archivo de texto. 

Por lo que respecta a la forma de funcionamiento del programa, debe ser 
fácil seguirla. Simplemente, lee los datos, acumulando la suma, hasta que se 
llega al final del archivo. Obsérvese que el programa funciona incluso si data- 
file es nulo. 


Los archivos como parámetros 
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Es instructivo escribir de nuevo el programa precedente en forma de proce- 
dimiento que tome como parámetro un archivo y escriba la suma de los com- 
ponentes del mismo. 

Supondremos que deseamos sumar tres archivos separados, de modo que 
el uso de un procedimiento se hace natural. El programa para realizarlo es el 
siguiente: 


program suma3archivos(archivol, archivo2, archivo3, output); 
(* Suma los componentes de cada uno de los tres archivos *) 
type 

realfile = file of real; 
var 

archivo1,archivo2,archivo3: realfile; 
procedure sumarchivo(var datafile: realfile); 
(* Imprime la suma de todos los componentes de datafile «) 
var 

sum: real; 

x: real; 
begin 

reset(datafile); 

sum:= 0; 

while not eofídatafile) do 

begin 

read(datafile, x); 
sum:= sum + X; 

end; 

writeln(“Sum =>”, sum); 

end; (* sumfile x) 


begin (x* programa principal x) 
sumfile(archivol); 
sumfile(archivo2); 
sumfile(archivo3),; 

end. 


Obsérvese cómo el parámetro para sumfile se ha declarado como un pará- 
metro var. Si esto se omitiera, la primera acción al llegar a 


sumfile(archivol); 


sería copiar el argumento en el parámetro. Esto exigiría copiar todo el archivol, 
lo cual es algo tan desaforado que el PASCAL lo prohíbe absolutamente. Los 
parámetros de archivos han de ser siempre parámetros var. 

El programa sirve también para ilustrar un problema suscitado antes. Se 
trata de que todos los archivos externos han de declararse en el encabezamien- 
to del programa y que, por consiguiente, no hay forma en PASCAL de crear 
dinámicamente un nombre de archivo. Ello significa que no existe equivalente 
de la sentencia de BASIC 


PRINT “TECLEE EL NOMBRE DEL ARCHIVO QUE SE VA A 
USAR:”; 

INPUT S$ 

FILE $43: S$ 


(aunque, como ya hemos dicho, tu PASCAL local puede tener una amplia- 

ción —tal vez un parámetro adicional para reset y rewrite— que ayude a con- 

seguir el mismo efecto). Por tanto, si deseáramos sumar cuatro archivos en 

vez de tres, tendríamos que cambiar el programa anterior en tres formas: 
e para añadir el archivo4 al encabezamiento del programa; 


e para declarar el archivo4; 


e para aplicar sumfile al archivo4. 


Operaciones sobre archivos 


““¿Qué pasaría si yo quisiera aplicar sumfile a input?””, dijo Bill, con un 
brillo en sus ojos que desmentía la aparente inocencia de su pregunta. 

Desgraciadamente, la respuesta es que el programa fallaría, porque sum- 
file sitúa a su parámetro en el estado inicial (resef), y no se puede hacer eso con 
input. Ni tampoco se puede incluir dentro del procedimiento una comproba- 
ción tal como 


if datafile < > input then reset(datafile); 
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No es posible comparar nombres de archivos. 

Esto recuerda en cierto modo a los registros. No se puede hacer nada con 
los registros excepto asignarlos. Los archivos, sin embargo, son todavía un poco 
peores. No es posible ni siquiera asignar un archivo a otro. Todo lo que se 
puede hacer es pasarlos como parámetros var, usarlos como argumentos para 
procedimientos incorporados, tales como el get, y emplearlos como referencia 
para la venta actual. 

Los cokneys londinenses, que pronuncian fail (fracasar) lo mismo que file 
(archivo), es posible que al hacerlo estén pensando en el PASCAL. 


Archivos y matrices 


Ya hemos observado que la declaración de un archivo se parece en algo 
a la de una matriz o array, como evidencian las declaraciones 


a: array [1..100] of real, 
f: file of real; 


Si mencionamos las diferencias entre estos dos conceptos, ello reforzará 
algunas de las propiedades de los archivos del PASCAL. 

En primer lugar, puede verse que un archivo, a diferencia de un array o 
matriz, puede tener un tamaño ilimitado, sujeto, desde luego, al de tu máqui- 
na y al de su memoria de reserva o apoyo. Ello no significa, sin embargo, que, 
si declaras de nuevo a todas tus matrices como archivos, vayan a desaparecer 
todos tus problemas. Los problemas surgen porque sólo podemos leer los ar- 
chivos secuencialmente y (lo que es peor) sólo podemos escribirlos secuencial- 
mente. Lo cual quiere decir que, incluso si cambiamos un solo elemento, tene- 
mos que escribir de nuevo todo el archivo. 

En segundo lugar, si alternamos la lectura y la escritura, tenemos que estar 
continuamente haciendo reset y rewrite en el archivo. 

Así, con sólo unos cuantos programas, puedes utilizar los archivos en for- 
ma cómoda y conveniente para almacenar grandes matrices o arrays. Sin em- 
bargo, si tu PASCAL local te ofrece archivos de acceso aleatorio, y si no te 
preocupa excesivamente la portabilidad, las oportunidades serán mucho 
mayores. 


Propiedades especiales de los archivos de texto 
A A SR TA A RA > MAN 


Hasta ahora, la mayor parte de todo lo que hemos dicho es aplicable por 
igual a los archivos de texto y a los binarios. La única facilidad adicional que 
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hemos encontrado para los archivos de texto ha sido la capacidad para leer 
y escribir diversos tipos de datos diferentes y para convertirlos a forma interna. 

Los archivos de texto poseen además otra importante propiedad: están di- 
vididos en líneas, las cuales van separadas por caracteres de ““cambio de lí- 
nea”, o “retorno de carro””. En algunos lenguajes, estos cambios de línea son 
caracteres reales, que se pueden manipular al igual que cualquier otro. En otros, 
como el BASIC, el cambio de línea es un carácter hipotético. El PASCAL adop- 
ta una posición intermedia: el cambio de línea cuenta como un carácter, pero 
cuando lo leemos obtenemos un espacio. Así, si los datos de entrada del archi- 
vo de texto (input) constan de las líneas 


23 
4 
1 


y ejecutamos el programa 


for k:=1 to 5 do 
begin 
write(inputl); 
get(input); 
end; 


con la ventana posicionada inicialmente en el carácter *2””, nuestra salida es- 
tará formada por los cinco caracteres **2””, “*3””, espacio, *“4””, espacio. La 
ventana termina apuntada al carácter “x””. 

Esto pone de manifiesto el segundo defecto que tiene nuestro programa bus- 
cador del carácter “dos puntos””: a medida que va copiando la entrada a la 
salida, todos los cambios de línea se convierten en espacios. 

Aunque el cambio de línea nos aparezca como un espacio, hay un medio 
para detectar su presencia. Esto se hace por medio de la función incorporada 
eoln, que es similar a la función eof. La función eoln sólo devuelve o produce 
el valor true si la ventana está posicionada en el fin de una línea. 

La función eoln se puede utilizar para eludir una de las limitaciones del 
PASCAL. El fragmento de programa que mostramos a continuación lee una 
línea de caracteres y los reúne formando con ellos una cadena o string. En esta 
forma, consigue el efecto de la lectura de una cadena. El código, que al mismo 
tiempo introduce una cadena y la imprime en la salida, es el siguiente: 


const 
maxlonglínea = 80; 

var 
linentrada: packed array [1..maxlonglínea] of char; 
Kk: integer; 


longlínea: 0..maxlonglínea; 
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begin 
for k:=1 to maxlonglínea do (x* borrar la línea x) 
linentrada[k]: =>”; 
longlínea: = 0; 
while not eoln(input) do 
begin 
if longlínea < maxlonglínea then 
longlínea: = longlínea + 1 
else 
(x* ... dar mensaje de error... x); 
read(linentradallonglínea)); 
end); 
(+ Ahora pasa el carácter de cambio de línea, de modo que la próxima 
entrada llegue en una línea nueva x) 
get(input); (xo, alternativamente (véase más adelante): readln; x) 


(* Ahora escribe la línea que acaba de leer x) 
writeln(linentrada); 


(x* Lo que precede escribe todos los espacios que haya al final de la 
linentrada. Las sentencias que siguen constituyen un perfeccionamiento 
que elude esos espacios 
for k:=1 to /longlínea do 

write(linentrada[k])); 
writeln; 


*) 


Los procedimientos writeln y readlIn 
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En BASIC existe una gran diferencia entre 


PRINT X; 
y PRINT X 


Como sabes, la última de estas sentencias pone fin a la línea actual (da sali- 
da a un cambio de línea, si lo prefieres), mientras que la primera permite que 
se produzca más salida en la misma línea. 

En PASCAL, como ya hemos indicado en el capítulo 6, los equivalentes 
de las sentencias BASIC anteriores son 


write(x); 
y writeln(x); 


así, el procedimiento writeln pone fin a una línea, mientras que el write no 
lo hace. Del mismo modo exactamente que en BASIC se puede emplear 


PRINT 


como una sentencia por sí sola, en PASCAL se puede utilizar 


writeln; 


por sí sola. Una sucesión de sentencias tales como 


writeln; writeln; writeln; 


es útil para escribir una serie de líneas en blanco. Al igual que write, writeln 
tiene como primer argumento un nombre opcional de archivo. Suponiendo que 
f sea un nombre de archivo, lo que sigue son ejemplos de lo que hemos dicho: 


writeln(f, x); 
writeln(f); writeln(f); (+« dos líneas en blanco en el archivo f x) 


El PASCAL soporta también un procedimiento incorporado readIn, que 
no tiene equivalente directo en BASIC. Del mismo modo que writeln añade 
un cambio de línea una vez que haya salido el último de sus argumentos, ha- 
ciendo así que la salida posterior aparezca en una nueva línea, readIn, una vez 
que se ha leído el último de sus argumentos, salta el resto de la línea actual, 
de modo que los datos posteriores se tomen de la línea siguiente. Así, si X es 
una variable entera (integer), y la sentencia 


readIn(k); 
se ejecuta con los datos de entrada 


23 24 se ha perdido 
Kio 


k tomará el valor 23, se saltarán los datos **24 se ha perdido””, y la ventana 
se quedará apuntando al carácter x del comienzo de la nueva línea. 
Obsérvese que en una sentencia como 


readin(a, b, c); 


es completamente legal que los datos correspondientes a a, b, y c estén bien 
en una sola línea o bien en tres líneas separadas, como es normal para un read. 
La única diferencia que existe en relación con un readIn es que salta hasta des- 
pués del primer cambio de línea siguiente al valor suministrado para c. 

Al igual que writeln, readln se puede emplear aislada o sola, sin lista de 
argumentos, para saltar al comienzo de una línea nueva. 
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El PASCAL proporciona también, como adjunto o complemento de wri- 
teln, otro procedimiento incorporado 


pagelf) 


que inicia una página nueva en el archivo f. 
Estos procedimientos, readln, writeln y page, sólo se pueden utilizar en ar- 
chivos de texto. 


El final-de-archivo en los archivos de texto 
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En muchos sistemas operativos, el final de un archivo de texto sólo puede 
venir después de una línea completa. Es como si el final-de-archivo fuese un 
carácter imaginario que viniese al comienzo de una línea. Esto repercute sobre 
el uso de la función eof en archivos de texto. Cuando se compruebe si ha llega- 
do el eof, deberemos tener posicionada la ventana en el principio potencial de 
una línea. Por consiguiente, las siguientes líneas de programa no funcionarán: 


read(x); 
if eoflinput) then (x ... *); 


La razón de ello es que read deja la ventana en el carácter siguiente al nú- 
mero que se acaba de leer. Suponiendo que el usuario suministrase la línea 


23 


la ventana estaría apuntada al carácter de cambio de línea posterior al “3”. 
(Recuerda que, si miras efectivamente a este carácter, éste se convierte en un 
espacio.) Por tanto, eof será siempre false. 

Para solucionarlo, se deberá leer el carácter de cambio de línea, de modo 
que la ventana quede apuntada al comienzo de la línea siguiente, cosa que se 
puede hacer por medio de 


read(x, nextchar); 


en donde nextchar se declara como una variable char, o, mejor todavía, por 
medio de 


readln(x); 
Esto último es un perfeccionamiento, ya que absorbe cualesquiera espa- 


cios (o, en realidad, cualesquiera otros caracteres) que sigan al valor de x, pero 
sólo es aplicable si se sabe que el elemento de datos suministrado para x se 


encuentra al final de una línea. (De no ser así, los ““otros caracteres”? que nos 
saltáramos podrían corresponder a datos vitales.) 

Hay, no obstante, una solución más limpia y más fiable que cualquiera de 
estas dos alternativas. Consiste en escribir una función texteof, que equivale 
a “saltar los espacios (si los hay) hasta que se llegue a un carácter que no sea 
espacio, o al final de una línea, y entonces realizar eof””. Una vez que se haya 
definido esta función, puedes usarla libremente en lugar de eof siempre que 
estés explorando un archivo de texto en contextos en los que los espacios ro 
tengan significado. Este es un buen ejemplo de la creación de una herramienta 
para la realización de lo que, en otro caso, sería una tarea difícil. 

La función texteof se define en la forma siguiente: 


function texteofívar f. text): Boolean; 
(* Explora a lo largo del archivo f hasta llegar a un no-espacio o al final 
de una línea; produce el valor true si f está entonces en eof +) 
var 
paraexplor: Boolean; (+ false si queremos seguir adelante exploran- 
do en busca de espacios *) 
begin 
repeat (x bucle para explorar los espacios que haya <+) 
paraexplor: = true; (* el valor de defecto, o default +) 
if not eof(f) then 


if fi= ” then 
begin 
paraexplor: = eoln(f); (* no explorar más allá del final de 
línea x) 
get(/); 
end; 


until paraexplor; 


texteof.= eoff); 


end; (x texteof x) 


Entrada/salida interactivas 


Los primeros implementadores del PASCAL visualizaron los dispositivos 
de entrada/salida como lectores de tarjetas, impresoras de línea y otros seme- 
jantes. 

Cualquier intento de interacción utilizando una terminal se enfrentaba al 
desastre. Incluso el intento de preparar un programa PASCAL en cualquier 
otro medio que no fuese las tarjetas estaba erizado de riesgos, tales como el 
que se tomase como un número de secuencia todo aquello que apareciese des- 
pués de la columna 72. Algunos de estos compiladores andan todavía por ahí, 
induciendo a sus usuarios a entregarse a la bebida o al BASIC. 
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Vamos a mencionar algunos de los problemas, a fin de que puedas reír aho- 
ra, antes de las lágrimas que vendrán después. 

Uno de ellos es que algunos compiladores PASCAL conservan la informa- 
ción de salida en buffers (o memorias temporales) más bien extensos, de, por 

“ejemplo, 1.024 caracteres. La información sale de ellos sólo cuando el buffer 
está lleno o cuando el programa haya terminado de ejecutarse. Entonces, la 
conversación con los programas de PASCAL adopta un aire bastante curioso. 
Uno puede insistir en sus preguntas o comunicaciones en la entrada, y el orde- 
nador permanece callado. Luego, de repente, cobra vida, disparándonos un 
chorro de 1.024 caracteres y respondiéndonos a preguntas que habíamos te- 
cleado hacía un buen rato. (Estos buffers pueden ocasionar problemas cuando 
hay fallos de programa a causa de errores; a menudo se pierde el último buffer 
incompleto, con el resultado de que la depuración se convierte en un bonito 
juego de las adivinanzas.) Los buffers, desde luego, están pensados para hacer 
más eficientes las transferencias a y desde cinta magnética y disco, y el fallo 
interactivo es un desafortunado efecto secundario. 

Los buffers se aplican a las entradas, al igual que a las salidas. Concreta- 
mente, muchos sistemas PASCAL procesan la entrada interactiva línea a lí- 
nea, con el resultado de que no examinan la entrada hasta que se pulsa la tecla 
RETURN. Otros sistemas PASCAL, principalmente en microordenadores, ofre- 
cen la entrada en el llamado *“*modo no elaborado”” (raw mode), mediante el 
cual se trata o procesa inmediatamente cualquier carácter que teclee un usua- 
rio interactivo. Consulta tu manual local en busca de estos detalles; es muy 
posible, en cualquier caso, que te encuentres con que la entrada interactiva es 
objeto de un tratamiento no-estándar. 

Otro problema que surge está relacionado con la definición de read. El PAS- 
CAL hace avanzar la ventana hasta el carácter siguiente al último que se haya 
leído. Si este último se encuentra al final de una línea —o si ya se ha empleado 
readln en vez de read—, el PASCAL hace avanzar la ventana hasta el inicio 
de la siguiente línea. Muchos compiladores de PASCAL nos piden en este mo- 
mento que introduzcamos la línea siguiente. Esto se hace antes de haberse tra- 
tado la línea tecleada anteriormente. El resultado, en condiciones estables, es 
que siempre estamos tecleando con un adelanto de una línea sobre la que en 
cada momento acabe de ser tratada. En consecuencia, si el programa produce 
invitaciones o avisos (prompts), éstos se referirán a la línea que se había te- 
cleado anteriormente. Así, una conversación podría desarrollarse en la forma 
siguiente (siendo lo escrito en minúsculas la parte correspondiente a la máqui- 
na): 


... JUAN 

¿Cómo te llamas? 26 

¿Cuántos años tienes? NO EL PASCAL 

¿Cuál es el mejor lenguaje de programación en cuanto a entrada/salida? 


Las cosas se hacen aún peores si nos fallan los poderes psíquicos y alguna 
de las respuestas nos sale equivocada. En conjunto, el resultado es que uno 
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de los mayores placeres de la vida, como es la conversación, se queda bastante 
aguado. 

También se producen problemas parecidos si nuestro programa imprime 
una respuesta para cada línea de entrada, por ejemplo: 


64 

no es una potencia de dos 
23 

es una potencia de dos 

32 

no es una potencia de dos 


(Cada respuesta se refiere a la penúltima entrada.) 

Llamaremos a éste el problema del desfasamiento. Si tu compilador PAS- 
CAL presenta este tipo de problemas, tal vez puedas escribir algunos procedi- 
mientos un tanto arfificiosos que te ayuden a vencer las dificultades. Véase 
en Kaye (1980) un buen estudio de los mecanismos implicados en ello. Otra 
alternativa es pasarse a un compilador que haya pensado algo en el usuario 
interactivo. 

Un último problema relacionado con la entrada interactiva es que el PAS- 
CAL da por sentado que la persona situada en la terminal es perfecta y no 
se equivoca nunca. Si los datos tienen un formato equivocado —por ejemplo, 
si se introduce una letra allí donde se espera un número—, el PASCAL da un 
mensaje de error y pone fin inmediatamente a la ejecución. 

Una conversación, en un programa de enseñanza con ayuda del ordena- 
dor, podría desarrollarse en la forma siguiente (suponemos aquí que el pro- 
blema del desfasamiento está ya resuelto): 


¿Cuántas son dos y dos? 

5 

Lo siento, Jaime, eso no está del todo bien, prueba de nuevo. 

$ (a Jaime se le ha olvidado pisar la tecla de las mayúsculas para el *4”) 
Error en los"datos de entrada 

Procedimiento lecturarespuesta interrumpido 

Fin de la ejecución. 


Entonces, es probable que las teclas de la terminal se humedezcan con las 
lágrimas de Jaime. 

No existe forma alguna de eludir este problema (a menos que tu PASCAL 
tenga una ampliación o extensión no estándar), como no sea escribir tus pro- 
cedimientos propios que tomen la entrada carácter por carácter, y la convier- 
tan a la forma numérica cuando ello sea necesario. Entonces, si existe cual- 
quier error, podrás dar al usuario un mensaje amistoso y pedirle que lo intente 
de nuevo. 
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Comprobación interactiva del fin-de-archivo, o eof 


Incluso si tienes un buen compilador interactivo, habrás de ser cuidadoso 
si quieres vencer completamente el problema del desfasamiento. El código que 
sigue pone de manifiesto el problema: 


suma:= 0; 

while not eof(input) do 

begin 
write (“Suma hasta ahora =”, suma, *, teclee el número siguiente:”); 
readIn(x); 
suma: = suma + X; 

end; 

writeln(“Suma total =>”, suma); 


En este programa se utiliza read/n, como recomendamos anteriormente, por- 
que entonces el eof funciona correctamente. (Es posible que hubiera sido me- 
jor emplear la función texteof, pero ello habría hecho este comentario más com- 
plicado.) 

Aun en el caso de que tu compilador interactivo sea lo bastante inteligente 
para no desfasarse a causa del mismo readIn, todavía lo hará como consecuen- 
cia de un problema lógico asociado con la función eof. La única forma en que 
el PASCAL puede saber si hay un final de archivo, es pedirte otra línea de 
entrada y ver si la hay o no. (Suponemos que el fin de archivo en una terminal 
se indica tecleando algún carácter especial al comienzo de la línea.) Así, al usua- 
rio se le pide que teclee una línea todas las veces que se ejecute while not eof(in- 
put). Esta línea es utilizada entonces por la sentencia readln que viene tres lí- 
neas más abajo. El efecto es que se pide al usuario que suministre su línea de 
entrada unas sentencias antes de lo que un vistazo poco atento al programa 
podría indicar. El problema es que hay un write que viene después del eof, 
pero antes que el read/n. Este write, por tanto, se ejecuta después de haber 
dado entrada a una línea, pero antes de que la misma haya sido tratada o pro- 
cesada. El resultado familiar es que la entrada se desfasa, por ejemplo: 


23 
Suma hasta ahora 
Suma hasta ahora 


O; teclee el número siguiente: 46 
23; teclee el número siguiente: (FIN DE ARCHI- 
VO, o eof) 


Suma total = 69 


Este es un problema lógico, no de tu compilador PASCAL, y la única for- 
ma de eludirlo es escribir de nuevo el programa de modo que el write venga 
antes que el eof. En el caso precedente, el resultado, un tanto lioso, es: 
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suma:= 0; 
write(“Suma hasta ahora= 0; teclee el número siguiente:”); 
while not eof(input) do 
begin 
readIn(x); 
suma: = suma + X; 
write(“Suma hasta ahora =”, suma, *, teclee el número siguiente: ?); 
end; 
writeln(“Suma total=”, suma); 


Dado que la comprobación interactiva de eof te va a ocasionar problemas, 
el mejor consejo es que lo pienses cuidadosamente antes de utilizarla. ¿Sería 
mejor formular tu programa de otra manera que permita evitar el eof? Una 
alternativa es preguntar una y otra vez al usuario interactivo si tiene más da- 
tos, y parar cuando conteste negativamente. Otra es emplear algún valor de- 
terminado que funcione como terminador para el conjunto de datos de que 
se trate; frecuentemente, el valor cero es adecuado para ello. 

Esta misma extremada cautela ha de aplicarse al uso interactivo de eoln. 


Formatos de salida 


Como último tema importante de este capítulo, consideraremos ahora los 
formatos de salida. Al llegar a este punto, hemos de confesar que los writes 
de todos los ejemplos dados hasta ahora en este libro han empleado unos for- 
matos de salida muy poco refinados, y que en muchos casos sus resultados no 
serían agradables de ver; el PASCAL provee un medio para lograr algo mejor. 

Hay facilidades análogas, pero más potentes, en aquellos BASIC que per- 
miten el empleo de una cláusula USING en una sentencia PRINT. La cláusula 
USING se aplica a la sentencia PRINT entera, pero las facilidades de control 
de formato del PASCAL se aplican a argumentos individuales de write o wri- 
teln. La más útil de las facilidades PASCAL es la capacidad para agregar, a 
un elemento que se haya de imprimir, un número entero (integer) que repre- 
sente una anchura mínima de campo. El ejemplo que sigue ilustra la sintaxis 
correspondiente: 


wrinteln(“Los totales para case”, caseno: 2, “son”, sumaa: 10, sumab); 


Como puede verse, se escribe un signo de “dos puntos”*(:) después de cada 
elemento que haya de tener una anchura mínima de campo. En este ejemplo, 
caseno (que suponemos que es un entero o integer) tiene una anchura mínima 
de campo de dos; esto significa que normalmente se imprimiría con dos carac- 
teres. La regla es bastante directa si caseno está entre 10 y 99. Si caseno está 
formado por una sola cifra, la regla es que se alinee por la derecha, es decir, 
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poniendo un espacio delante. Si caseno es mayor de 99, es evidente que no ca- 
brá en dos caracteres. Sin embargo, normalmente esto no constituye un error 
en PASCAL; lo que se hace es imprimir el valor utilizando el menor número 
de caracteres posible. Recuérdese que el entero 2 representa la anchura míni- 
ma del campo, y no necesariamente la utilizada en realidad. Así pues, cuando 
queramos que un elemento se imprima siempre con el menor número de carac- 
teres posible, podemos darle 1 como anchura mínima de campo. 

Las anchuras mínimas de campo se pueden aplicar a elementos de cualquier 
tipo de datos, aunque su aplicación más frecuente es con enteros y reales. Si 
se omite la anchura mínima de campo —como hemos venido haciendo en to- 
dos nuestros ejemplos hasta que hemos llegado a esta sección—, tendremos 
una anchura de campo que vendrá definida por la implementación para el tipo 
de datos de que se trate. Consulta los detalles en tus manuales PASCAL loca- 
les. En nuestro ejemplo precedente, sumaa se imprime con una anchura de 10, 
pero sumab se imprime con la anchura de campo que tenga asignada por de- 
fecto su tipo de datos. 

En la práctica, estas anchuras asignadas por defecto suelen ser largas, con 
lo que, si hubiéramos omitido el **:2”” después de caseno, una línea de salida 
podría tener este aspecto 


los totales para el case 4 son ... 


Parece que el Sr. 869704 ha persuadido a los escritores de compiladores de que 
la salida usualmente está formada por columnas muy separadas de cifras, en 
lugar de por una combinación legible de texto y números. 


Longitud de la parte fraccionaria 
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Si se especifica una anchura mínima de campo, pueden ir tras ella otros 
dos puntos y otro entero, al que se denomina la longitud de la parte fracciona- 
ria, por ejemplo: 


writeln(*“Suma=>”, sumaa: 8: 3, * unidades. >; 


Si se expresa una longitud para la parte fraccionaria, el valor a imprimr 
ha de ser un número real. En el ejemplo precedente, la variable sumaa se im- 
prime con una anchura mínima de campo de 8 y una longitud de la parte frac- 
cionaria de 3, lo cual significa que habrá tres cifras después del punto decimal. 
(NV. del E.: Debido a que en la notación del ordenador de los números decima- 
les se emplea el punto en lugar de la coma del castellano, hemos referenciado 
con “punto flotante”” en lugar de “coma flotante”” a lo largo del texto. De 
igual forma hemos procedido en cuanto a “punto decimal”” en lugar de “*co- 
ma decimal””.) Así, si sumaa tiene el valor 12.34567, la salida sería 


Suma= 12.346 unidades. 


Obsérvese que se imprimen dos espacios delante del valor de sumaa, aseguran- 
do así que la anchura del campo alcance el mínimo de 8. 

De hecho, la presencia de la longitud de la parte fraccionaria hace que cambie 
la forma en que se imprimen los números reales. Si no se expresa longitud al- 
guna para la parte fraccionaria, el valor sale en notación de “punto flotante”, 
por ejemplo: 


1.2345670000E + 01 


Por tanto, la longitud de la parte fraccionaria es sin duda un ““bueno””, por- 
que hace que los números salgan en la forma que, para casi todos nosotros, 
es más legible. 

Resumiendo, los valores por defecto que obtenemos si omitimos la anchu- 
ra mínima de campo o la longitud de la parte fraccionaria, suelen ser lo que 
en realidad nos interesaba menos. 


Otros puntos 


Obviamente, las facilidades para controlar el formato sólo son aplicables 
si la salida va a un archivo de texto, y no a uno binario. 

En realidad, las facilidades para el control de formato del PASCAL po- 
seen una ventaja sobre la cláusula USING del BASIC. Esta ventaja consiste 
en que la anchura mínima de campo y la longitud de la parte fraccionaria pue- 
den ser expresiones cuyos valores se pueden cambiar en el curso de la ejecu- 
ción. Como ejemplo un tanto absurdo, la sentencia 


for k:= 1 to 5 do 
writeln(k: Kk); 


produciría esta salida: 


De un modo más práctico, estos controles de formato se pueden definir 
utilizando constantes con nombre, lo que hace más fácil cambiarlas, por ejem- 
plo: 


const 
anchuradecase = 2; 
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var 
caseno: integer; 

begin 

(+ 


*) 


writeln(“Los totales para el case”, caseno: anchuradecase, * son...?); 


Como último punto concerniente a los formatos, obsérvese que la senten- 
cia PASCAL + 


write(a, b, c); 
se asemeja a la de BASIC 
PRINT A; B; C; 
más que a 
PRINT A, B, C, 
En otras palabras, el PASCAL no inserta espacios adicionales entre los ele- 
mentos que hayan de imprimirse. Esto significa que usualmente somos noso- 


tros los que tenemos que poner espacios en el comienzo y/o el final de las ca- 
denas o strings en las que haya intercalados números. Por ejemplo, 


writeln(*Resultado del case ”, caseno: 2); 
produciría, si caseno tuviera el valor 18, la siguiente línea: 
Resultado del case18 
En consecuencia, la sentencia precedente estaría mejor expresada así: 
writeln(*Resultado del case ”, caseno: 2”); 
Si se imprimen números positivos sin control de formato, se imprime un 
espacio para el signo (mientras que delante de los números negativos se impri- 


me un signo menos); así pues, no hace falta incluir un espacio más al final 
de una cadena precedente. 


Tipos de datos encarcelados o recluidos 


Hemos indicado anteriormente cuáles eran los tipos de datos que podían 
leerse y escribirse en archivos de texto. En esta última sección diremos algo 
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más acerca de los infelices tipos de datos que están recluidos o encarcelados 
dentro del PASCAL, y que no pueden ser objeto de entrada y salida. 

Los que más destacan entre estos prisioneros son los tipos definidos por 
el usuario. Si vuelves al programa adelgazador del capítulo 7, podrás recordar 
que había en él un tipo día que representaba los días de la semana. También 
contenía una variable hoy del tipo día. El programa podría mejorarse dando 
salida al valor de hoy en la tabla de resultados. Sin embargo, la sentencia 


write(ho y); 


no imprimiría el valor de hoy, que, por ejemplo, podría ser martes; en lugar 
de hacerlo, el compilador daría un mensaje de error. Si realmente quieres pro- 
ducir la salida de un objeto del tipo día, la mejor forma de hacerlo es escri- 
biendo un procedimiento, que podría tomar la forma siguiente: 


procedure escribedía(d: día); 
(x* Escribe el día de la semana representado por d x) 
begin 
case d of 
lunes: 
write('Lunes”); 
martes: 
write('Martes?): 
miércoles: 
write( Miercoles”); 
Jueves: 
write( Jueves”); 
viernes: 
writel Viernes”); 
sábado: 
write(“Sábado”); 
domingo: 
write(*Domingo”?); 
end; 
end; (x escribedía x) 


La escritura de estos procedimientos es aburridísima. Su único mérito es 
que si tienes un amigo o un pariente de esos que siempre están ansiosos por 
ayudar, pero que no son muy buenos programando, estos procedimientos se- 
rán un pasto ideal para él, y a ti te permitirá conseguir un poco de paz. 

Un procedimiento para entrada semejante a éste sería todavía peor, ya que 
los nombres de los días se han de leer y ensamblar carácter por carácter. Es 
poco probable que la tía Amy o el pequeño Willy consigan introducir correc- 
tamente el procedimiento. 

Desde luego, es una verdadera lástima que los tipos definidos por el usua- 
rio sean prisioneros, ya que si no lo fueran resultarían aún más útiles. 
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Gráficos 


También los registros se encuentran entre los prisioneros, aunque si se les 
trata campo por campo pueden escurrirse para entrar o salir. Este mal trato 
dado a los registros resultará una gran sorpresa para los lectores familiariza- 
dos con lenguajes tales como el COBOL, en los que uno de los fines centrales 
de los registros es definir los formatos de entrada/salida. 

Desde luego, se puede introducir o extraer cualquier tipo de datos si se usa 
un archivo binario de dicho tipo; pero tales archivos no son legibles para los 
mortales, sino únicamente para los programas de ordenador. 


Sumario 


Para mucha gente, usar un ordenador sin capacidad para gráficos es como 
un árbol sin frutos o una primavera sin flores. El PASCAL no dispone de fa- 
cilidades para gráficos, ni siquiera de las muy elementales que son necesarias 
para desplazar un cursor. Como se trata de una omisión tan estrepitosa, son 
muchos los compiladores que le han agregado sus propias facilidades gráficas 
no-estándar. En este punto, todo lo que podemos hacer es remitirte a tu ma- 
nual PASCAL local. 
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Tras la lectura de este capítulo, es probable que te hayas quedado con la 
impresión de que el sacar o meter algo en tu programa PASCAL es una em- 
presa tan difícil como la de recorrer todo el campo de golf de St. George equi- 
pado sólo con un putter. Bien, no te dejes abatir demasiado. Usualmente po- 
drás completar finalmente tu tarea, especialmente si tu PASCAL contiene unas 
ampliaciones razonables, y sobre todo si te construyes tus herramientas pro- 
pias, que te ayuden para vencer los bunkers y fortines del PASCAL. 

A pesar de todo, queda la sensación de que tu tarea es mucho más dura 
de lo necesario. 


No piensas más que en los conjuntos. 


Reprobación dirigida a un adoles- 
cente programador de PASCAL 
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Conjuntos 


Tras debatirnos chapoteando en las turbias aguas de la entrada/salida, va- 
mos a volver ahora a una clara y cristalina laguna. En vez de enfrentarnos a 
un capítulo largo y complicado, empezamos uno breve y (así lo esperamos) 
sencillo. 

Retornamos otra vez al tema de los tipos de datos, y vamos a describir uno 
nuevo que deberá cambiar tu.modo de pensar en relación con algunos de tus 
programas. 


Introducción a los conjuntos 


En PASCAL se puede definir un tipo de datos que es un conjunto de obje- 
tos de algún otro tipo de datos. A este último se le llama tipo base del conjun- 
to. El tipo base de un conjunto puede ser cualquier tipo, excepto el real (de 
números reales). Usualmente, es un tipo definido por el usuario, un tipo 
subrango, o char. 

Aparte del PASCAL, son pocos los lenguajes de programación bien cono- 
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cidos que soportan conjuntos; e incluso en el PASCAL, algunos compiladores 
de las primeras hornadas imponían onerosas restricciones sobre el tamaño de 
los mismos. El resultado de ello es que los conjuntos permanecen ignorados 
para muchos programadores de PASCAL. Es una lástima, porque los conjun- 
tos pueden ser increíblemente útiles, y contribuir en gran manera a que un pro- 


grama sea una descripción más próxima y ajustada del problema cuya solu- 
ción se busca. 


Un ejemplo de conjunto 


Nuestro primer ejemplo de conjunto tiene como tipo base un tipo definido 
por el usuario. Este tipo base consiste en una sucesión de nombres de lengua- 
jes de programación. Por tanto, se trata de un conjunto de lenguajes de pro- 
gramación. Se define en esta forma: 


type 
lenguajes = (Pascal, BASIC, BCPL, SIMULA, ALGOL60, ALGOL68, 
COBOL); 
lenguajesconocidos = set of lenguajes; 


Por lo que antecede, puedes ver que para definir un conjunto se escribe set 
of seguido por el tipo base. Una vez hecha esta declaración, puedes usar el 
tipo de datos en la forma normal y, en particular, puedes declarar variables 
como de dicho tipo de datos, por ejemplo: 


var 
lenguajesPrimple: lenguajesconocidos, 
lenguajesMudd: lenguajesconocidos; 
sabelotodo, casosinremedio: lenguajesconocidos; 


Las variables del tipo de datos lenguajesconocidos pueden tomar como va- 
lor cualquier subconjunto del conjunto completo. En uno de los extremos, es- 
te subconjunto puede ser nulo (el conjunto vacío), o, en el otro extremo, pue- 
de ser el conjunto de los lenguajes de programación conocidos por una perso- 
na determinada. 

Cuando se quiera asignar un valor a una variable de lenguajesconocidos, 
se puede usar un constructor de conjunto. El constructor de conjunto se escri- 
be haciendo una lista de aquellos elementos que se desee incluir, y encerrando 
la lista entre corchetes, por ejemplo: 


lenguajesPrimple: =[Pascal, BCPL]; 
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(* Como los miembros del conjunto se pueden escribir en cualquier or- 
den, lo anterior también se puede escribir así: 
lenguajesPrimple: =[BCPL, Pascal]; +) 
LenguajesMudd: = [BASIC]; 
casosinremedio: =[ ]; (x* un conjunto vacio x) 
sabelotodo: = [Pascal, BASIC, BCPL, SIMULA, ALGOL60, ALGOL68, 
COBOL]; 


En realidad, existen miles de lenguajes de programación, aunque sólo una 
docena aproximadamente son los ampliamente conocidos. Si ensancháramos 
nuestro tipo de datos lenguajes hasta que estuviese formado por 100 lengua- 
jes, resultaría muy aburrido escribir el constructor de conjunto que habría de 
asignarse a sabelotodo. Para aliviar esta molestia, el PASCAL permite que los 
elementos de que se compone un constructor de conjunto puedan especificarse 
por medio de subrangos del tipo base. Así, podríamos escribir 


sabelotodo: = [Pascal.. COBOL]; 


Como PASCAL es el primer valor del tipo base y COBOL es el último, esto 
equivale a especificar todos los valores incluidos en el tipo base. 
A continuación damos otros dos ejemplos: 


sabemás: = [Pascal..BCPL, ALGOL60..COBOL]; (x* todos excepto 
el SIMULA xx) 
sabealgunos: = [Pascal..BCPL, ALGOL60, COBOL]; 


Un conjunto se parece algo a una matriz o array Booleana, en cuanto que 
cada posible miembro del conjunto puede estar presente o no; en otras pala- 
bras, su presencia puede ser ““verdadera”” o ““falsa””. Llevando esta idea un 
paso más adelante, un conjunto es equivalente a la ““cadena de bits”? que se 
encuentra en los lenguajes ensambladores y en algunos lenguajes de alto nivel, 
es decir, una sucesión de valores 1 (o “'verdadero””) y 0 (o **falso””). Sin em- 
bargo, los conjuntos del PASCAL son mucho mejores que las cadenas de bits, 
porque facilitan la lectura del programa al desterrar la influenca del Sr. 869704 
o, en este caso, la del Sr. 110101000101001000. 


Operaciones con conjuntos 


Los conjuntos no son ciudadanos de segunda, como algunos tipos de datos 
del PASCAL. Bien es verdad que no se pueden usar como entrada/salida, pe- 
ro, al menos, existen algunos operadores que se les pueden aplicar. En espe- 


£6,?? 


cial, se pueden aplicar los operadores “*+””, “—”” y *““x””. Probablemente, tú 
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podrás deducir del significado de estos Operadores en aritmética lo que los mis- 
mos significan cuando se les aplica a conjuntos. Así, el conjunto 


x+y 


es aquél cuyos elementos son elementos de x, o de y, o de ambos. El nombre 
técnico para esto es la unión de conjuntos. Alternativamente, y si persistimos 
en contemplar los conjuntos como cadenas de bits, un “*+>”” es un “or” lógico 
(el **x”” resultará ser el ““and”” lógico). En nuestro ejemplo, la unión 


lenguajesPrimple + lenguajesMudd 
es el conjunto 


[Pascal, BCPL, BASIC] 


y la unión de cualquiera de nuestras variables con sabelotodo seguirá siendo 
el conjunto de todos nuestros lenguajes. 
El operador menos significa la diferencia de conjuntos. Así 


x— Y 


es aquel conjunto cuyos elementos pertenecen a x, pero no a y. En nuestro 
ejemplo, 


sabelotodo — lenguajesPrimple 


es el conjunto 
[BASIC, SIMULA, ALGOL60, ALGOL68, COBOL] 


Finalmente, el operador **x” significa la intersección de conjuntos. Es de 
tal modo que 


Xx* y 
es el conjunto cuyos elementos pertenecen a x y a y. En nuestro ejemplo, 
lenguajesPrimple x lenguajesMudd 


es el conjunto vacio. En cambio, la intersección de sabelotodo con cualquier 
conjunto z es idéntica al valor de éste. 

Debes ser capaz de pensar ejemplos en los que sean útiles estos operadores 
aplicados a los conjuntos. En nuestro caso particular, la unión e intersección 
de lenguajesconocidos sería útil para un programa destinado a asignar equi- 
pos de programadores a tareas de programación que exigiesen el conocimiento 
de ciertos lenguajes. 


Operaciones de relación con conjuntos 


” TEE] 


A los conjuntos se les pueden aplicar, además de los “+”, “—” y “x”, 
varios operadores de relación. La forma en que éstos funcionan es la siguiente: 


e x= yes verdadera cuando x e y sean conjuntos idénticos; 

e x <> yes verdadera cuando x e y no sean conjuntos idénticos; 

e x <= yes verdadera si todos los elementos de x lo son también de y; 

e x >= yes verdadera si todos los elementos de y lo son también de x; 

e los operadores *>” y *<” no pueden aplicarse a conjuntos. 
Dadas estas reglas, la relación 


lenguajesPrimple x lenguajesMudd = casosinremedio 


es verdadera, porque los dos lados de la ecuación con conjuntos vacíos. Ade- 
más, 


[BASIC, SIMULA] = [SIMULA, BASIC] 


es verdadera porque el orden de los elementos es indiferente. Como tercer ejem- 
plo, 


sabeloto > =x 
es verdadera para cualquier conjunto de lenguajes x. 


Otro ejemplo, cuyo impacto inicial es sorprendente, es que 


lenguajesMudd > = lenguajesPrimple 
y lenguajesPrimple > = lenguajesMudd 


son ambas falsas. Así que ten cuidado de no aplicar directamente a las relacio- 
nes entre conjuntos tu forma de pensar relativa a las relaciones entre números. 

Finalmente, no sólo puedes usar en los conjuntos cuatro de los operadores 
relacionales existentes, sino que tienes también un nuevo operador: el in o “en”. 
Su funcionamiento es tal que 


ein x 


es verdadera si e es un elemento del conjunto x. El tipo de datos de e tiene 
que ser igual que el tipo base del conjunto x. En nuestro ejemplo, 


BASIC in lenguajesPrimple 


es falsa, porque Primple, ciertamente, no admite conocer el BASIC. 
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Expresiones dentro de constructores de conjuntos 


En los ejemplos que hemos dado hasta ahora, los elementos incluidos en 
los constructores de conjuntos han sido siempre constantes. En realidad, pue- 
den ser cualquier tipo de expresión, como se ve en 


var 
x: set ot 1..31; 
P,q: integer; 
egin 
(x 
. *x) 
x:=[lp,q — 1..q +3, 19, 20]; 
(x* o. 
*) 
x= x + [p..ql; 
(x 
*) 


Si p es menor que q, entonces [p..q] es, desde luego, el conjunto vacío. 


Un ejemplo completo con caracteres 


Los conjuntos son útiles también para simplificar expresiones Booleanas 
en las que intervengan muchas operaciones or. Vamos a dar un ejemplo de 
esto en el que se usa un conjunto cuyo tipo base es char. Este es, en efecto, 
uno de los tipos base más populares, y tal vez nuestro ejemplo ponga de mani- 
fiesto la razón de ello. 


program cuentacaracteres(input, output); 
(* Cuenta, dentro del texto de entrada: 
l. el número de letras o cifras 
2. el número de caracteres de puntuación (*.*0 *%*0 %*0“”) x) 


, 


var 
cuentaletrascifras: 0..maxint; 
cuentapuntuación: 0..maxint; 
carácteractual: char; 
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begin 
cuentaletrascifras: = 0; 
cuentapuntuación: = 0; 
while not eof(input) do 
begin 

read(carácteractual); 

(x* En la sentencia que sigue se da por supuesto que el juego de caracte- 
res es tal que todas las letras tengan códigos adyacentes, y lo mismo 
las cifras +) 

if carácteractual in [“a”..Z?, “A?..Z?, *0”..*9”] then 
cuentaletrascifras: = cuentaletrascifras + 1; 
if carácteractual in [*.?, *?, *;?, *:] then 
cuentapuntuación: = cuentapuntuación + 1; 
end; 
writlen(“El número de letras o cifras es”, cuentaletrascifras); 
writeln(*El número de caracteres de puntuación es”, cuentapuntuación); 
end. 


Este programa no usa variables del tipo de conjunto de datos. Todo lo que 
usa son constructores de conjuntos y la facilidad in; no obstante, tanto una 
cosa como la otra desempeñan un considerable papel para hacer que el pro- 
grama sea fácil de escribir y de comprender. 


Un segundo ejemplo completo 


Un segundo ejemplo completo nos muestra un programa relativo a un ta- 
blero de tiro con dardos. Un juego que un extremado aficionado o un borracho 
consumado pueden completar en un tiempo razonable es el siguiente: hacer 
blanco en todos los números del 1 al 20, en cualquier orden. 

El programa que sigue da entrada a los tanteos o puntuaciones e imprime 
un mensaje cuando se ha hecho blanco en todos los números. 


program coberturadardos(input, output); 
(x* Lee los números constantemente hasta que cada uno de los números 
1 a 20 se haya producido por lo menos una vez x) 
var 
númerosacertados: set of 1..20; 
tanteo: 1..50 (x* un tablero de dardos contiene también 25 y 50 x) 
begin 
númerosacertados: =[ ]; (x inicialmente, el conjunto vacío x) 
repeat 
read(tanteo); 
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if tanteo< = 20 then 
númerosacertados: = númerosacertados + [tanteo]; 
until númerosacertados = [1..20]; 
writeln(“x*xx*x ¡MUY BIEN! Ha cubierto todos los números”); 
end. 


La línea interesante es la que actualiza a númerosacertados. Obsérvese que, 
cuando el operador “*+>”” se aplica a conjuntos, han de ser conjuntos sus dos 
operandos. Por consiguiente, el segundo operando ha de ser [tanteo], que es 
un conjunto que contiene un solo elemento, el valor del tanteo. La sentencia 


númerosacertados: = númerosacertados + tanteo; 


sería un error, porque tanteo no es un conjunto. No tenemos duda de que tú, 
como nosotros, te olvidarás de esta regla una y otra vez cuando te pongas a 
escribir un programa. Sin embargo, tal vez el ejemplo precedente te sirva de 
recordatorio cuando te preguntes muy intrigado cuál será el error de sintaxis 
del que se te avisa. 


Conjuntos desemejantes 


Al igual que, dentro de un solo programa, se puede emplear cualquier nú- 
mero de matrices de distintos tipos y formas, también se puede emplear cual- 
quier número de conjuntos de diferentes tipos base. Así, nuestra variable /en- 
guajesPrimple podría aparecer en el mismo programa que númerosacertados. 
Lo que, sin embargo, no se puede hacer es aplicar las operaciones con con- 
juntos a tipos desemejantes, por ejemplo, 


lenguajesPrimple + númerosacertados 


lenguajesPrimple = númerosacertados 


Tales operaciones carecen de cualquier significado, y Perkins las señalará co- 
mo errores con toda razón. 


Restricciones en relación con los conjuntos 


Como ya hemos mencionado antes, algunos de los primeros compiladores 
PASCAL imponían importantes restricciones sobre el tamaño de los conjun- 
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tos. Típicamente, un conjunto estaba limitado a un reducido número de ele- 
mentos, digamos unos 60. Como quiera que casi todos los juegos de caracteres 
tienen más de 60, esto hacía imposible cualquier set of char. Frecuentemente, 
la restricción era aún más abrumadora. No se permitían tipos tales como 


x = set of 58..62; (x* límite superior > 60 x) 
y = setof “a..Z; 


La razón era que los límites de los subrangos han de estar entre 0 y 59, o, en 
el caso de los caracteres (char), los códigos internos han de estar dentro de este 
margen. La mayoría de los juegos de caracteres no satisface esta restricción 
impuesta sobre char. Si se aplica esta restricción, nuestro ejemplo de verifica- 
ción de letras y cifras podría ser inutilizable, porque el carácter sometido a ve- 
rificación y/o los elementos del constructor de conjunto podrían hallarse fue- 
ra del margen permitido. 

Tenemos la esperanza de haber llegado a tiempos más felices, y de que los 
viejos compiladores estén siendo sustituidos por otros escritos por gentes que 
aprecien el valor verdadero que tienen los conjuntos. Sin embargo, es prob. - 
ble que todavía siga habiendo ciertas restricciones sobre el tamaño de los con- 
juntos, por razones de buena implementación. Es poco probable que se nos 
vaya a permitir decir 


granconjunto = set of integer; 


porque el número de enteros posibles es verdaderamente muy grande. En efec- 
to, es probable que esté prohibido cualquier tipo base que implique enteros 
negativos o enteros positivos grandes. 

Tal vez la divisoria más importante en el tamaño de los conjuntos sea su 
capacidad para abarcar o no al juego de caracteres, constituido normalmente 
por 128 ó 256 caracteres. Si los escritores de tus compiladores han hecho el 
esfuerzo necesario para conseguirlo, no dejes de sacar a sus desvelos todo el 
fruto posible explotando al máximo los conjuntos y sus posibilidades. 


Otras operaciones con conjuntos 


““Observo que no hay funciones incorporadas que trabajen sobre con- 
juntos””, dijo Bill. “Por ejemplo, nada que cuente el número de elemen- 
tos. Por lo que veo, los conjuntos son como la mayor parte de las cosas 
en el PASCAL: hermosos objetos que son absolutamente ideales, a con- 
dición de que no queráis usarlos en programas reales.” 


Desde luego, no hay funciones incorporadas para los conjuntos, pero en 
realidad esto es una buena característica del PASCAL. Como ya hemos dicho 
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anteriormente, los lenguajes gigantescos como ballenas no son lo que el usua- 
rio necesita. 

En las operaciones con conjuntos, el PASCAL es lo bastante breve y elás- 
tico como para poder ser utilizado satisfactoriamente. Por ejemplo, el proble- 
ma de contar los elementos de un conjunto, expuesto por Bill, se puede resol- 
ver en la forma siguiente. (Suponemos que el conjunto que se ha de contar 
es lenguajesMudd): 


count:= 0; 
for k:= Pascal to COBOL do 
if k in lenguajesMudd then 
count:= count + 1; 


UV ZS 


Gl "SY 


7% 


Si estamos seguros de que nos esperan penas en el futuro, ¿por qué nos 
las arreglamos siempre para preparar otras nuevas? 


RUDYARD KIPLING 
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Almacenamiento 
o memoria 
dinámica 


Deficiencias de la memoria estructurada en bloques 


En el mundo de los lenguajes estructurados en bloques, del que el PAS- 
CAL forma parte, el almacenamiento o memoria empleado para las variables 
sigue una limpia y ordenada estructura de bloques anidados. Cada vez que se 
entra en un procedimiento, se reserva espacio de memoria para las variables 
locales de dicho procedimiento; al producirse el retorno desde ese procedimiento, 
este espacio de memoria queda liberado. Además de esto, en el programa prin- 
cipal se declara algún almacenamiento, que se halla disponible todo el tiempo; 
a éste se le denomina el almacenamiento o memoria g/obal, porque existe du- 
rante todo el tiempo o vida de trabajo del programa. La palabra “global” re- 
vela la excluyente concentración del pensamiento de los programadores; el pro- 
grama en que estamos trabajando en cada momento constituye todo el mundo 
para nosotros. 

Desgraciadamente, los problemas del mundo real no siempre encajan en 
esta simple disciplina del almacenamiento o la memoria. Consideremos, a tí- 
tulo de ejemplo, un programa para el control de los movimientos de aviones 
en un aeropuerto. Suponemos que el programa se ocupa de tareas tales como: 


e control del tráfico aéreo mientras los aviones están en espera para 
aterrizar; 
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e asignación de los aviones a las distintas puertas de embarque; 


e llevar una lista de los aviones en espera para despegar. 


(Tal vez no confíes en tu capacidad y temas que, si fueses tú el responsable 
de tal tipo de programa, el resultado sería el mayor desastre aéreo de todos 
los tiempos: cincuenta aviones cayendo a tierra simultáneamente; si te ocurre 
eso, piensa que el programa es sólo una simulación —tal vez parte de un juego— 
y no el problema real.) 

Cada avión lleva asociadas varias propiedades (por ejemplo, número de vue- 
lo, tamaño del avión, número de pasajeros a bordo y tiempo programado de 
llegada). Por consiguiente, es natural que cada avión se represente por medio 
de un registro. Será necesario interconectar los registros de los aviones indivi- 
duales mediante su inclusión en listas; más adelante estudiaremos los detalles 
precisos de todo ello. El programa necesitará muchas, como listas de aviones 
en espera para aterrizar, de aviones en espera para el despegue, de puertas de 
embarque disponibles, de vuelos programados que tienen retraso, de vuelos 
charter especiales, y tal vez incluso listas de pasajeros. Todas estas listas tienen 
dos rasgos comunes; 


e son dinámicas —crecen y se contraen; 


e son globales —existen durante todo el funcionamiento del programa. 


Considera la forma en que podrías representar estas listas usando las faci- 
lidades del PASCAL que ya te hemos descrito. Está claro que cada lista ha 
de representarse como un array o matriz de registros. El problema surge cuan- 
do se trata de determinar el tamaño de cada array. Este tamaño ha de ser una 
constante fijada de antemano; aun cuando tu PASCAL te permita declarar 
una matriz, con una variable como límite superior, por ejemplo, 


array[1..n] of aviones; 


ello no servirá de mucha ayuda, ya que sigue siendo necesario expresar el ta- 
maño de la matriz (el valor de n en nuestro ejemplo) antes de asignarlo. 

Si tienes que fijar el tamaño de tus arrays o matrices por adelantado, has 
de hacerlos tan grandes como sea posible. Sería bastante desafortunado que 
tuvieras que decir a un avión que llegara al aeropuerto: “Lo siento: no cabe 
usted en mi sistema de control de tráfico aéreo porque mi matriz está llena.” 
Sin embargo, si haces grandes todas tus matrices, se te acabará la capacidad 
de memoria; en la práctica, los tamaños de tus matrices habrán de ser limita- 
dos, y lo de que una matriz se llene es una posibilidad real. 

La gran desventaja de un esquema como el precedente, que utiliza matrices 
O arrays separados, es que si uno de ellos llega a llenarse, es muy probable 
que haya algunos de los otros que dispongan de abundante capacidad no utili- 
zada; por ejemplo, si hay una saturación de aviones, es probable que exista 
una falta de pasajeros en espera y de puertas de embarque libres. Desgraciada- 
mente, no hay forma de aprovechar esta memoria no utilizada. 


Un problema análogo 


Para ver en qué forma se puede resolver este problema, vamos a conside- 
rar una analogía. Tenemos un grupo de personas que utilizan los servicios de 
una biblioteca de préstamo de libros. Por cada libro que te lleves, necesitas 
un vale o ticket. A tu familia se le han adjudicado veinte. Preguntas a cada 
miembro de tu familia cuál es el número máximo de libros de la biblioteca que 
necesitará tener en préstamo en cualquier momento. El total asciende a treinta 
y cinco. Por tanto, si en el seno de tu familia tratas de asignar tickets a cada 
persona de ella con arreglo a sus necesidades máximas, se te terminarán los 
vales de la biblioteca. 

Resuelve el problema observando que es muy poco probable que todos los 
individuos de la familia utilicen su capacidad máxima de préstamo de libros 
al mismo tiempo. Por consiguiente, con los veinte vales o tickets de préstamo 
constituyes un fondo común que compartirá toda la familia; los miembros de 
ella tomarán un ticket de dicho fondo cuando lo necesiten, y lo devolverán 
a él cuando hayan terminado. Lo más probable es que los veinte tickets resul- 
ten suficientes para cubrir la necesidad aparente de treinta y cinco. 


La pila 


Por tanto, una solución para el problema del almacenamiento dinámico 
que necesitamos para nuestras listas consiste en poner en un solo fondo toda 
la capacidad de almacenamiento o memoria. Inicialmente, este fondo de me- 
moria está libre, es decir, no asignado. Cuando es necesario añadir un nuevo 
elemento a una de las listas, se toma *““en préstamo”” una parte de esta memo- 
ria libre, y se la usa para contener al elemento de la lista. Si, en una etapa pos- 
terior, se deja de necesitar este elemento de lista (por ejemplo, cuando un avión 
sale del sistema), el espacio de memoria correspondiente a él se puede “dejar 
libre” y devolverlo al fondo de memoria libre. Las ventajas de este esquema 
son las siguientes: 


e sólo se usa memoria cuando es realmente necesario. Por tanto, sólo 
se agotará la memoria del sistema si toda ella se ha utilizado verda- 
deramente; 


e la memoria que quede libre en una lista podrá ser utilizada de nuevo 
más tarde, por la misma lista o por otra; incluso, acaso, por una lista 
con un tipo de datos diferente. 


El PASCAL proporciona precisamente un mecanismo de esta clase. Per- 
mite mantener estructuras de datos separadas, normalmente de tipos de datos 
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independientes, todas las cuales comparten el mismo fragmento o espacio de 
memoria. La memoria no viene y se va cuando entramos y salimos en los pro- 
cedimientos, sino que está controlada por instrucciones específicas para tomar 
espacio prestado y para dejarlo libre. Por consiguiente, puedes utilizarla para 
objetos que sean globales de tu programa. Al espacio de almacenamiento se 
le llama el montón o pila (en inglés, the heap) porque es un objeto amorfo, 
que no se usa en un forma estructurada en bloques. Cuando empezamos la 
ejecución de un programa PASCAL, toda la memoria principal de nuestra má- 
quina que está sin utilizar se reúne en la pila. (Normalmente, la pila no está 
relacionada con la memoria de reserva, o backup). Una variable a la que se 
asigne espacio de almacenamiento desde la pila, recibe el nombre de variable 
dinámica. (Emplearemos el término “variable ordinaria”” para describir la clase 
de variables de las que nos hemos ocupado en forma exclusiva antes de este 
capítulo, es decir, las variables declaradas bajo el encabezamiento var). 


La utilización de la memoria dinámica 


Cuesta un esfuerzo bastante considerable aprender y dominar las facilida- 
des del PASCAL para el almacenamiento dinámico. Ello no es porque estas 
facilidades sean confusas o indebidamente complicadas —más bien al 
contrario—, sino porque implican un número de conceptos nuevos. 

El más importante de ellos es que las variables dinámicas no se declaran 
en la sección var del programa. De hecho, /as variables dinámicas carecen com- 
pletamente de nombres. En su lugar, se accede a ellas por medio de punteros. 


Punteros 


Llegamos ahora al último de los tipos de datos del PASCAL. Su nombre 
es el puntero. Una variable del tipo puntero se llama simplemente un puntero 
del mismo modo que una variable del tipo array se llama un array o matriz; 
puede que esto te suene un poco confuso, pero no lo es en la práctica. Un pun- 
tero apunta a una variable dinámica. Los dos son completamente interdepen- 
dientes en cuanto que: 


1) un puntero sólo puede apuntar a una variable dinámica. No puede, por 
ejemplo, apuntar a una variable ordinaria; 


2) la única forma en que se puede hacer referencia a una variable dinámica 
es por medio de un puntero. 


En nuestro ejemplo, las variables dinámicas son los registros asociados con 
aviones, puertas, etc., que constituyen los elementos de nuestras listas. Cada 
variable dinámica necesitará un puntero asociado con ella. 

En términos de implementación, un puntero es simplemente la dirección 
del byte (o de la palabra) en que empieza un fragmento de almacenamiento 
dinámico. Es posible que ya estés familiarizado con un concepto similar en pro- 
gramación en lenguaje ensamblador. En ese caso, puedes pensar en el puntero 
como en algo que puede apuntar a cualquier byte de la memoria o almacena- 
miento principal de tu ordenador. Entonces, la restricción expresada en 1) más 
arriba puede resultarte sorprendente. La finalidad de la misma, como vere- 
mos, es mantener a los programas dentro de una segura disciplina, y vedar los 
picarescos trucos que son posibles en lenguaje ensamblador. 


Los tipos de datos del almacenamiento dinámico 


En PASCAL, todas las variables, sean dinámicas o no, tienen un tipo de 
datos asociado. A las variables ordinarias se les da un tipo de datos cuando 
se declaran en la sección var. Esto es algo que no se puede hacer con las varia- 
bles dinámicas, puesto que carecen de nombre y no se las declara. En lugar 
de ello, se adosa el tipo de datos al puntero que apunta a la variable dinámica 
en cuestión. Las variables dinámicas son normalmente registros, por razones 
que ya veremos, de modo que este tipo de datos suele describir una estructura 
de registro. Un puntero se declara poniendo el símbolo **?”” como prefijo del 
tipo de datos al que ha de apuntar. (El tipo de datos ha de estar representado 
por un identificador; es la misma regla que se aplica al tipo de datos de un 
parámetro.) A continuación damos unos ejemplos de declaraciones, en las que 
suponemos que avión y puerta se declaran como registros bajo el encabeza- 
miento type: 


type 
punteroavión = 1 avión; 
punteropuerta = 1 puerta; 

var 
aviónqueaterriza: punteroavión; 
aviónquedespega: punteroavión; 
próximapuertalibre: punteropuerta; 


Aquí, aviónqueaterriza, aviónquedespega y próximapuertalibre son los tres 
punteros. El tipo asociado con un puntero es una característica vital del PAS- 
CAL. Ello significa que Perkins puede verificar el tipo de las variables dinámi- 
cas en la misma forma que en las ordinarias. Así, si cometes en tu programa 
alguna tontería, como hacer referencia a un avión cuando quieres decir una 
puerta, el compilador dará un aviso de error. Esto contrasta con lo que sucede 
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en algunos lenguajes, en los que tal tipo de error puede causar una corrupción 
de los datos que puede ser catastrófica, y que no se le notifica al usuario. 

Asociada con el tipo de datos del puntero hay una constante llamada nil. 
Un puntero puede apuntar a una variable dinámica, o tener el valor nil. Si en 
este momento no hay ningún avión aterrizando, se puede hacer la siguiente 
asignación: 


aviónqueaterriza: = nil; 


Los punteros son uno de los tipos de datos del PASCAL que no tienen mu- 
chos operadores asociados. Todo lo que podemos hacer es asignar un puntero 
a otro (incluyendo el caso de pase de parámetros), por ejemplo: 


aviónquedespega: = aviónqueaterrizas (= aterrizaje abortado xx) 


o comparar los valores de dos punteros empleando los operadores relacionales 
“=" 0 “<>”, por ejemplo: 


if aviónqueaterriza = aviónquedespega then (+ ... x) 


En ambos casos, asignación y comparación, los dos punteros que intervie- 
nen han de tener el mismo tipo de datos asociado. Si se pudiera asignar a un 
puntero un valor de cualquier tipo de datos asociado, la tarea de Perkins sería 
imposible, porque no sabría a qué estabas apuntando. (En la jerga de los orde- 
nadores, se dice que el PASCAL es strongly typed, o con fuerte influencia de 
los tipos; los tipos de datos de las variables, incluso los de aquellas que se di- 
reccionan indirectamente, se conocen de antemano.) 


Toma en préstamo y devolución o liberación 
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Supongamos que deseas tomar en préstamo algún espacio de almacenamien- 
to. Un avión que llega acaba de entrar en el área y deseas crear un registro 
para él y añadirle a la lista de aviones en espera para el aterrizaje. El espacio 
de almacenamiento o memoria se toma prestado por medio del procedimiento 
incorporado new, o “nuevo””. Este procedimiento toma como argumento su- 
yo un puntero. Su acción es tomar un fragmento de memoria, y hacer que el 
puntero apunte a él. El tamaño del fragmento de la memoria es el suficiente 
para contener una variable dinámica del tipo de datos asociado con el puntero. 

A continuación se da un ejemplo de llamada de new. 


var 
llegada: apuntdeaparato; 


begin 


(+ 
. *) 
new(llegada); 
(x 
*) 


Hay una forma de new o “nuevo”” más elaborada, que se puede emplear 
para economizar un poco de espacio cuando un registro tiene un campo de 
variantes. No nos preocuparemos de esto. Una llamada de new no asigna nin- 
gún valor al almacenamiento o memoria que adjudica, y así, lo primero que 
ha de hacer el programa con el nuevo almacenamiento es poner en él algunos 
valores. Pronto veremos la forma en que se hace. 

El procedimiento complementario del new es el dispose, que libera un frag- 
mento de memoria. Este también toma como argumento a un puntero, por 
ejemplo: 


dispose(aviónquedespega); 


Vale la pena hacer unas cuantas advertencias acerca de new y dispose. En 
primer lugar, no existe (normalmente) ninguna comprobación de seguridad con- 
tra el problema del puntero colgante (dangling pointer), en el cual se libera 
algún fragmento o espacio de almacenamiento y luego se sigue haciendo refe- 
rencia a él; ni hay tampoco comprobación alguna contra el error de liberar 
dos veces inadvertidamente el mismo espacio de memoria. Estos dos errores 
pueden producir un comportamiento imprevisible del programa. Es uno de los 
pocos ejemplos del PASCAL en que es posible hacer algo en contra de las re- 
glas sin que le cojan a uno. 

En segundo lugar, existe cierto número de compiladores PASCAL que no 
se comportan en la forma normal en lo que concierne al dispose. Algunos no 
hacen caso alguno de ese procedimiento, mientras que otros lo sustituyen por 
un mecanismo que hace que el montón se comporte como una pila auténtica 
o stack. Así pues, los programas que usan el dispose no son tan portátiles co- 
mo debieran. 


Referencias a las variables dinámicas 


Como ya hemos dicho, una variable dinámica carece de nombre. Para ha- 
cer referencia a ella, se escribe el nombre del puntero que apunta a la variable 
y se le pone después el signo **?””. Así, cuando se declara un puntero, se pone 
la flecha **?”” delante del tipo de datos, y cuando se le usa, se pone la flecha 
“*P”” detrás de él; indudablemente, esto ha de estar basado en una profunda 
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lógica, pero, sin embargo, esta regla es una verdadera fuente de triviales erro- 
res de sintaxis. 

Las variables dinámicas se pueden usar en cualquier parte en que sea posi- 
ble utilizar una variable ordinaria del mismo tipo de datos, por ejemplo: 


aviónquedespegal = aviónqueaterriza!; 


o, si aviónaparcado es una variable ordinaria del tipo avión, se puede decir 


aviónquedespega: aviónquedespega: aviónquedespega: 


aviónqueaterriza: aviónqueaterriza: aviónqueaterriza: 


KL343 KL343 


BD113 BD113 KL343 


a) Estado inicial b1) Tras la ejecución de b2) Tras la ejecución de 
aviónquedespega: = aviónquedespega 
aviónqueaterriza; en T:=aviónqueate- 
el estado inicial a) rrizaT; en el estado 

inicial a) 


Figura 11.1. Efectos de las asignaciones utilizando punteros. 


aviónaparcado: = aviónqueaterriza!; 
(x 


*) 


aviónquedespega!:= aviónaparcado; 


Para familiarizarnos mejor con los punteros, será valioso considerar la di- 
ferencia entre las dos sentencias alternativas 


(x* 1 x) aviónquedespega: = aviónqueaterriza; 
(* 2 x) aviónquedespegal:= aviónqueaterrizal; 


El primer caso es una asignación de un puntero a otro; se hace que el pun- 
tero aviónquedespega apunte a la misma variable dinámica que aviónqueate- 
rriza. Así, cualquier referencia subsiguiente a aviónquedespega producirá la 
misma variable dinámica que una referencia a aviónqueaterriza. El segundo 
caso es una asignación de un registro a otro; el registro almacenado en la va- 
riable dinámica aviónqueaterriza se copia en la variable dinámica aviónque- 
despega. El resultado es dos copias separadas de la misma cosa. Desde luego, 
cualquier cambio subsiguiente en una de las copias no afecta a la otra. La fi- 
gura 11.1 muestra en forma gráfica la diferencia entre los dos casos. Inicial- 
mente, aviónqueaterriza apunta al registro correspondiente al avión KL343, 
y aviónquedespega apunta al registro correspondiente al avión BD113. 

Es posible que hayas notado la similitud entre esta notación para los apun- 
tadores y la correspondiente al uso de ventanas en archivos. Tal similitud no 
es accidental; puedes considerar una ventana como un puntero que señala a 
un archivo. 

Cuando se trata de un registro, es más frecuente la referencia a campos 
individuales que al registro completo. Si el registro es una variable dinámica, 
se sigue haciendo referencia a los campos en la forma normal, es decir, aña- 
diendo los nombres de los campos. Así, si númerodevuelo es un campo de avión, 
haremos referencia al númerodevuelo de la variable dinámica a la que apunta 
aviónqueaterriza en la forma siguiente: 


aviónqueaterrizal.númerodevuelo 


Sumario intermedio 


Ahora ya hemos tratado todos los conceptos nuevos que necesitas cono- 
cer. Esencialmente, todo lo que necesitas comprender son los punteros, y los 


procedimientos new y dispose. 
Hace falta practicar bastante para llegar a ser realmente diestro en el alma- 


cenamiento dinámico. La causa es, sin duda, que el nivel adicional de tortuo- 
sidad que suponen los apuntadores es una pequeña carga más para la mente. 
Más adelante, en este mismo capítulo, mostraremos algunos ejemplos más lar- 
gos, lo cual podrá contribuir a que los conceptos queden más claros. 

Las estructuras de datos figuran entre los objetos más importantes del tra- 
bajo con ordenadores. Esta expresión se emplea para abarcar a cualquier co- 
lección de elementos de datos relacionados entre sí. Así, los arrays o matrices 
y los registros son estructuras de datos. Sin embargo, cuando las estructuras 
de datos llegan a ser verdaderamente interesantes es cuando las variables diná- 
micas se enlazan o articulan con los punteros. 

Todo este conjunto constituye un área fascinante para el estudio y la expe- 
rimentación. Hay multitud de buenos libros que leer; uno de ellos es Data struc- 
ture techniques (Técnicas de estructura de datos), por T.A. Standish (1980). 
Si realmente aspiras a la profesionalidad en materia de ordenadores, has de 
leer la más grande obra de esta ciencia: The art of computer programming (El 
arte de la programación de ordenadores), por Donald Knuth (1973). No te de- 
jes asustar por las matemáticas que hay al principio; más adelante viene un 
abundante material que es eminentemente legible, aun cuando no domines las 
matemáticas. En particular, el volumen 1 contiene mucha y buena informa- 
ción acerca de las estructuras de datos. 

Apenas es posible leer una descripción de un trabajo avanzado de software 
sin encontrarse con un esquema de una elaborada estructura de datos. En la 
figura 11.2 tenemos un ejemplo de este tipo. 

La moraleja, pues, es perfectamente clara: a medida que vas pasando a ta- 
reas de programación más avanzadas, se va haciendo cada vez más importante 
el tener un buen dominio de las estructuras de datos. En realidad, tu mismo 
éxito puede depender de que elijas la estructura adecuada para la tarea de que 
se trate. 

Una lista como, por ejemplo, una de nuestras listas de aviones, es en reali- 
dad un ejemplo bastante sencillo de una estructura de datos. Sin embargo, co- 
mo éste no es un libro sobre estructuras de datos, nos limitaremos en él a este 
caso sencillo, esperando que lo domines y que después te sientas preparado 
para empresas más serias. 


Variables dinámicas enlazadas (linked) 


La misma finalidad del almacenamiento dinámico significa que el número 
de variables dinámicas en existencia en cualquier momento es algo que no se 
puede fijar de antemano. Por tanto, no se puede pensar siquiera en declarar, 
dentro de la sección var, un puntero que corresponda a cada variable dinámi- 
ca. La única forma posible de hacerlo sería tener una matriz o array de punte- 
ros, pero tal matriz habría de tener un tamaño máximo fijo, lo cual destruiría 
en gran medida el objetivo perseguido. 


La forma en que se resuelve este problema consiste en organizar a las va- 
riables dinámicas en una estructura de datos, cada uno de cuyos elementos con- 
tenga uno o más punteros a las otras variables dinámicas relacionadas con él. 
Necesitamos un puntero para acceder a la ““primera”” variable dinámica de la 
estructura. Todos los restantes elementos se pueden encontrar siguiendo una 
cadena de punteros que empieza con este primero. 


a 
E 


Figura 11.2, Ejemplo de una estructura de datos. (Reproducido con autorización de 
John Wiley and Sons de un artículo técnico por Turner, 1979.) 


Con nuestra sencilla estructura de datos —la lista— es fácil conseguirlo. 
Cada elemento de la lista es una variable dinámica que representa un registro, 
y dentro de éste reservamos un puntero que se usa para apuntar al elemento 
siguiente de la lista. Si el elemento actual de la lista es el último de ella, el pun- 
tero tendrá el valor nil. Con cada lista está asociada una variable ordinaria, 
que se llama la cabeza de la lista y apunta al primer elemento. Si una lista está 
vacía o nula, la cabeza tendrá el valor nil. Usualmente, la cabeza de la lista 
se declarará en forma global, ya que no ha de desaparecer mientras la lista 
esté en existencia. 

En la figura 11.3 vemos una lista de tres aviones, B4136, KLO026 y VA 113. 
El puntero cabezadelista constituye la cabeza de la lista. (Las posiciones en que 
hemos dibujado los bloques de memoria no importan en absoluto; cualquier 
disposición de estructura equivalente tendría el mismo significado.) 
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E 


BA136 


Figura 11.3. Una lista de tres aviones. 


Hemos dicho antes que normalmente las variables dinámicas suelen ser re- 
gistros. Esperamos que ahora veas por qué: cada variable dinámica es usual- 
mente una combinación de valores, algunos de ellos conteniendo información 
acerca del objeto que la variable dinámica representa, y otros (en nuestro ca- 
so) actuando como punteros a otras variables dinámicas subsiguientes. 


Estilo de programación 


Hemos insistido en que con cada variable dinámica debe haber asociado 
por lo menos un puntero. Si no hubiera ninguno, no podríamos hacer referen- 
cia a la variable, ni siquiera deshacernos (dispose) de ella. (Algunos lenguajes 
disponen de “recogida de basuras””, mediante la cual se deshacen automática- 


mente de las variables no referenciadas; el PASCAL no lo hace, si exceptua- 
mos que toda la memoria se libera al final mismo de cada ejecución, de modo 
que la próxima se inicie con la memoria otra vez virgen.) 

El estilo normal de programación es tener un puntero asociado con cada 
variable dinámica para hacer referencia a ella y para enlazarla a una estructu- 
ra de datos, más un número de “punteros errantes”” (roving pointers) utiliza- 
dos en el interior del programa para hacer referencia a las variables dinámicas 
que son de interés actual; por ejemplo, el avión que esté tomando tierra en 
este momento. 


Ejemplo de procedimientos de tratamiento de listas 


Dedicaremos el resto de este capítulo a algunos ejemplos concretos de frag- 
mentos de programa para manipular listas de aviones. Esperamos que por este 
medio te familiarices más con el almacenamiento dinámico. 

En primer lugar, declaramos los tipos de datos necesarios, cosa que se hace 
en la forma siguiente: 


type 
complemento = 0..1000; (* número de pasajeros en un avión x) 
vuelo = packed array [1..5] of char; (* una cadena de 5 caracteres x) 
apuntdeaparato = Tavión; 
avión = 
record 

númerodevuelo: vuelo; 

pasajeros: complemento; 

(* otros campos 


. ki) 
siguiente: apuntdeaparato; 
end; 


El apuntador al siguiente avión no tiene que ser forzosamente el último cam- 
po del registro avión, pero, por convención, las listas se definen normalmente 
en esta forma. 

Obsérvese que hemos dado un nombre, apuntdeaparato, al tipo de datos 
constituido por un indicador a un avión. Este nombre hará falta cuando escri- 
bamos procedimientos que tomen como parámetros a tales punteros; recuér- 
dese que el tipo de un parámetro ha de ser un tipo de datos provisto de nombre. 

Puesto que tenemos un nombre, será bueno usarlo en todo lugar en que 
sea posible. Si tu compilador insiste en la coincidencia de nombres, un pará- 
metro apuntdeaparato concuerda solamente con un argumento apuntador- 
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aparato y no con un argumento, aparentemente idéntico, Tavión. Así pues, 
hemos usado apuntdeaparato en el campo siguiente de avión. 

El ejemplo pone de manifiesto un punto interesante. La referencia Tavión 
viene antes que la definición de avión. (Si hubiéramos puesto la definición de 
apuntdeaparato después de avión, ello habría dado lugar a un error cuando 
se produjera la existencia de indicadoraparato dentro de avión.) Esta situa- 
ción, en la que el nombre de un tipo de datos sigue al símbolo **?””, es el único 
caso en PASCAL en que se puede usar un identificador antes de haberlo de- 
clarado. Sin embargo, el identificador ha de ser declarado dentro de la misma 
sección type. El objeto de esta suavización de las reglas normales es para que 
se puedan definir estructuras de listas, tales como nuestro avión. 


La impresión de una lista 
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Nuestro primer ejemplo expone un procedimiento que avanza secuencial- 
mente a lo largo de una lista. Esos procedimientos son muy corrientes. La ta- 
rea específica del procedimiento de nuestro ejemplo es imprimir el númerode- 
vuelo de cada avión incluido en la lista. Es como sigue: 


procedure escribevuelos(apuntdelista:apuntdeaparato); 
(* Escribe los números de todos los vuelos incluidos en la lista de aviones 
dada x) 
var 
apuntactual: apuntdeaparato;, (« empleado para apuntar sucesiva- 
mente a cada avión x) 
begin 
apuntactual: = apuntdelista; 
while apuntactual < >nil do 
begin 
writeln(apuntactuall .númerodevuelo); 
apuntactual: = apuntactual * siguiente; (« pasa al avión siguiente x) 
end; 
end; (* de escribevuelos x) 


El procedimiento precedente nos muestra un mecanismo típico para el tra- 
tamiento de listas. El bucle while recorre una lista en forma sucesiva hasta que 
se encuentra un puntero nil. Cada vez que se recorre el bucle, se actualiza un 
puntero (apuntactual) para pasar al elemento siguiente de la lista. Obsérvese 
que este procedimiento funciona correctamente en una lista nula, así como en 
una lista parcial, es decir, el caso en que el argumento apunta a un lugar inter- 
medio de una lista en lugar de hacerlo a la cabeza de la misma. 

El profesor Primple prefiere escribir el procedimiento en una forma repeti- 
tiva O recursiva, a saber: 


procedure profescribe(apuntdelista: apuntdeaparato); 
(x* Especificación igual a la de escribevuelos, pero éste funciona en 
forma repetitiva x) 
begin 
if apuntdelista < >nil then 
begin 
writeln(apuntdelista Y. númerodevuelo); 
profescribelapuntdelista *.siguiente); 
end; 
end; (x profescribe x) 


Sin embargo, si el profesor llegara alguna vez a ejecutar realmente sus pro- 
gramas, hallaría que este elegante procedimiento repetitivo no es muy prácti- 
co. Si la lista contiene 1.000 elementos, profescribe se llama a sí mismo repetiti- 
vamente hasta una profundidad de 1.000 llamadas. Cada llamada ocupa espa- 
cio dentro del ordenador, con lo que en un ordenador pequeño el resultado 
probable es una abrupta interrupción de la impresión hacia la mitad de la lista. 

A pesar de ello, vale la pena mostrar la creación del profesor. Demuestra 
la forma en que la repetición puede simplificar la estructura lógica de un pro- 
cedimiento mediante la eliminación de algunos de los cansados detalles de house- 
keeping (preparación o acondicionamiento). En nuestro caso, se elimina el pun- 
tero apuntactual que se desplaza a lo largo de la lista. Para estructuras de 
datos más complicadas que las listas, y en casos en los que no surja una repeti- 
ción muy profunda, los procedimientos repetitivos son sencillos y eficaces. 


Adición de elementos a una lista 


El procedimiento que sigue añade un nuevo avión a una lista. El espacio 
de almacenamiento o memoria para el nuevo avión se toma en préstamo en 
forma dinámica. El campo siguiente del avión se pone en el punto al que apunta 
el parámetro apuntinserción, y el mismo apuntinserción se actualiza para que 
apunte al nuevo avión: 


procedure agregaalista(var apuntinserción: apuntdeaparato; f. vuelo; c: 
complemento); 

(x* Crea el registro para un nuevo avión, conteniendo el vuelo y el com- 
plemento correspondientes, y lo agrega a la lista en un punto anterior 
al avión que hay en apuntinserción x) 

var 
aptr: apuntdeaparato; («* un apuntador temporal +) 

begin 
new(aptr); 
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(x* Ahora pone los valores en el nuevo registro x) 
aptr 1.númerodevuelo: = f, 
aptr 1.pasajeros: = Cc; 
aptr 1.siguiente: = apuntinserción; (* añade el resto de la lista origi- 
nal después del nuevo avión x) 
apuntinserción: = aptr (x enlaza el nuevo avión a la lista x) 
end; (x* agregaalista x) 


Obsérvese que es necesario escribir var antes del parámetro apuntinserción 
porque el procedimiento cambia el valor de este puntero, para hacer que apunte 
al elemento recién insertado. Este procedimiento se puede utilizar para inser- 
tar un elemento en cualquier lugar de una lista, sea en la cabeza, al final, 
o en un punto intermedio. La siguiente secuencia de llamadas muestra la cons- 


trucción de una lista: 


cabezadelista: = nil; (x la lista es nula inicialmente <+) 

agregaalista(cabezadelista, “KL123”, 90); (+ pone en la lista al primer 
avión x) 

agregaalista(cabezadelista, BR456”, 110); (x* lo añade en la cabeza 
de la lista, delante de 
KL123 x) 


(x* En este punto, la lista consta de BR456 seguido de KL123 x=) 


agregaalista(cabezadelista 1.siguiente, “ICO01”, 0); 
(* El ICO01 se agrega después del BR456 y antes del KL123 +) 


Una vez ejecutadas las tres llamadas de agregaalista, la lista está formada 
por BR456, seguido de /C001, al que a su vez sigue KL123. La forma en que 
se construye se muestra en la figura 11.4. 

La siguiente secuencia de código es, de alguna manera, más general. Agre- 
ga un nuevo elemento (L.4789) al final de la lista a la que apunta cabezadelista, 
independientemente del número de aviones que existan ya en ella. 


if cabezadelista= nil then 
agregaalista(cabezadelista, “LAT89, 99) 
else 
begin 
apuntactual: = cabezadelista; 
(x* Halla el final de la lista x) 
while apuntactual 1.siguiente < > nil do 
apuntactual: = apuntactual ?.siguiente; 
agregaalista(apuntactual 1.siguiente, “LA789”, 99); 
end; 


Superficialmente, el código precedente es excesivamente complicado. Mu- 
cho más sencillo es 


cabezadelista: [_u ] cabezadelista: 


KL123 


50 


a) inicialmente b) después de la adición de KL123 


cabezadelista: ú cabezadelista: 
BR456 BR456 


ye 


KL123 


c) después de la adición de BR456 d) después de la adición de /C001 


Figura 11.4. Creación de una lista. 
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apuntactual: = cabezadelista; 

while apuntactual < > nil do 
apuntactual: = apuntactual 1 siguiente; 

agregaalistalapuntactual, “LAT89”, 99); 


El único problema que tiene este sencillo código es que no funciona. La 
razón es que agregaalista cambia el valor de su parámetro var. La intención 
de este cambio es alterar un puntero dentro de la lista donde ha de hacerse 
la inserción. Nuestro sencillo código no cambia la lista en ninguna forma; to- 
do lo que hace es actualizar el valor del puntero temporal apuntactual de mo- 
do que apunte al nuevo elemento. Así que necesitamos el código más compli- 
cado, que pasa como argumento o la cabeza de la lista o bien un puntero en 
el interior de la lista que queremos cambiar. Si hallas que esta expresión es 
complicada, trata de resolver el problema tú mismo. 


“Sólo es complicado porque no aprovecháis las ventajas de la repeti- 
ción””, dijo el profesor. **Todo lo que necesitáis es un procedimiento así 


procedure agregaalfinalivar aparatos: apuntdeaparato, f. vuelo; c. complemento), 
(x* crea un nuevo avión y lo agrega al final de la lista +) 
begin 
if aparatos = nil then 
agregaalistalaparatos, f, C) 
else 
agregaalfinal(aparatos *.siguiente, f, C); 
end; (* de agregaalfinal x) 


y a continuación escribís 
agregaalfinal(cabezadelista, “LAT89%, 99); 


Así de sencillo.””? Un punto para Primple. 


Para borrar o suprimir (delete) de una lista 


En nuestro ejemplo final se borra o suprime un avión de una lista, ilustran- 
do así el uso del procedimiento dispose. El procedimiento correspondiente es 
el que sigue: 


procedure suprimedelista(var apuntdelista: apuntdeaparato); 

(* Suprime de una lista el avión al que apunte apuntdelista; apuntde- 
lista es el campo “siguiente” del avión al que se ha de borrar. Cuando 
se haya de borrar el primer avión, apuntdelista es la cabeza de la lista +) 


214 


var 
enlace: apuntdeaparato; (« campo “siguiente? del avión borrado «x) 
begin 
if apuntdelista = nil then 
begin 
writeln(*xx=x* Error: no se puede borrar o suprimir nada de una lista 
nula?)y; 
(x ... Facilite información adicional... x) 
halt; (x* ..o, mejor, llame a alguna rutina de recuperación... x) 
end; 
enlace: = apuntdelista! siguiente; (* apunta al avión siguiente al que 
ha de suprimirse x) 
dispose(apuntdelista); 
apuntdelista: = enlace (« actualiza para apuntar al avión siguiente +) 
end; (* suprimedelista x) 


Dos puntos hemos de explicar acerca del procedimiento suprimedelista. El 
primero se refiere a la depuración, o debugging. Al comienzo de este capítulo 
ya avisamos que la gente tiene problemas conceptuales para entender las es- 
tructuras de datos, tales como las listas; dicho de otro modo, sufre muchas 
equivocaciones. Tanto mayor, por consiguiente, es la importancia que tiene 
el diseñar los programas de modo que den buenos mensajes de error cuando 
las cosas van mal. Esa es la razón por la que hemos puesto la comprobación 
de errores al comienzo de nuestro procedimiento. Si la hubiéramos omitido, 
y se hubiese llamado a nuestro procedimiento con un argumento nil, el resul- 
tado habría sido (si Perkins estaba atento) un mensaje de error cuando se hizo 
referencia a apuntdelista 1 siguiente. Inevitablemente, habría sido un mensaje 
de tipo general acerca del mal uso de los punteros, en lugar de uno específico 
y concreto, como el que nosotros podemos dar. 

El segundo punto hacia el que queríamos llamar tu atención, es que has 
de ser muy cuidadoso para no hacer jamás referencia a nada de lo que te hayas 
deshecho por medio de dispose. Las tres últimas sentencias de nuestro proce- 
dimiento se podrían simplificar convirtiéndolas en: 


dispose(apuntdelista); 
apuntdelista: = apuntdelista 1.siguiente; 


pero esto está mal, porque apuntdelista 1 siguiente queda dentro del avión re- 
cién eliminado con dispose. De hecho, en algunos compiladores el procedimiento 
dispose repone su argumento a nil para disuadir de tal trapacería. 

Ahora mostraremos algunos ejemplos de llamada de suprimedelista. El ejem- 
plo más sencillo es el de supresión de la cabeza de la lista, 


suprimedelista(cabezadelista); 


La figura 11.5 muestra la forma en que esto funciona en el caso en que 
los dos primeros elementos de la lista sean 4B123 y CD456. 
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cabezadelista cabezadelista 


suprimido 
con dispose 


CD456 


AS 
+= 


b) tras la supresión del primer 


a) inicialmente 
elemento 


Figura 11.5. Supresión de la cabeza de una lista. 


Lo que sigue borraría o suprimiría a todos los aviones de una lista: 


while cabezadelista < > nil do 
suprimedelista(cabezadelista), 


Finalmente, el siguiente código suprimiría el último elemento de una lista: 


if cabezadelista < > nil then 
begin (* sólo suprime de una lista que no sea nula x) 
if cabezadelista 1.siguiente= nil then 
suprimedelista(cabezadelista) (x* sólo 1 avión x) 
else 
begin 
(x Halla el penúltimo avión de la lista x) 
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apuntactual: = cabezadelista; 
while apuntactual 1.siguiente 1.siguiente < > nil do 
apuntactual: = apuntactual 1 .siguiente; 
suprimedelistalapuntactual 1.siguiente); 
end; 
end; 


La aparente complicación adicional, haciendo un caso especial del primer 
elemento de la lista, tiene las mismas causas que ya vimos al agregar un ele- 
mento al final de una lista. 

Para suprimir el último avión, tenemos que cambiar el campo siguiente del 
penúltimo avión. Por tanto, la estrategia del programa precedente es hallar 
el penúltimo avión y entonces llamar a suprimedelista para que opere sobre 
el campo siguiente de éste. Este campo siguiente apunta al avión que se ha de 
suprimir. El código contiene un ejemplar de puntero bastante bonito, a saber: 


apuntactual 1. siguiente 1 siguiente 
Para entenderlo, consideradlo como 
(apuntactual ?.siguiente)! siguiente 


En otras palabras, tomamos el campo siguiente del apuntactual para obte- 
ner un puntero (el encerrado entre paréntesis), y luego usamos este puntero 
para extraer el campo siguiente de otro avión. Desde luego, se pueden cons- 
truir ejemplares aún más bonitos usando, en vez de nuestros dos punteros, una 
secuencia de cuatro o cinco; pero recuerda que cada nivel de puntero duplica 
probablemente los problemas de cualquier lector que intente entender lo que 
estás haciendo. 

También en este caso se puede escribir un procedimiento repetitivo que ha- 
ga en forma mucho. más limpia esta misma tarea, aunque la versión más larga 
que acabamos de ver contribuye a ilustrar algunos mecanismos. Otro punto 
para Primple. 


Punteros adicionales 


En algunas aplicaciones, las listas son largas y es bastante corriente que ha- 
ya la necesidad de hallar el final de una lista. Cuando esto ocurre, nuestros 
bucles con while, que buscan los finales de listas, consumen demasiado tiem- 
po; una alternativa es mantener una variable análoga a cabezadelista, pero que 
apunta al último avión de una lista. El mantenimiento de tal variable exige bas- 
tante housekeeping adicional. Pero, como ocurre con el pudding de carne y 
riñones de Heather, que lleva horas de preparación y proporciona sólo minu- 
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tos de delicia al comerlo, el esfuerzo puede valer la pena. En el caso de la opti- 
mización de un programa, uno invierte horas en el ajuste del programa, con 
el resultado de que el ordenador (así lo suponemos) saboree el exquisito placer 
de ejecutar un programa rápido. 


Sumario sobre los usos del almacenamiento dinámico 
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Para muchos problemas, no necesitarás almacenamiento dinámico; las ma- 
trices o arrays normales, y cosas análogas, servirán muy bien a tus necesida- 
des. Sin embargo, si empiezas a escribir programas para problemas más com- 
prometidos, te darás cuenta, sea cual sea tu campo de aplicación, de que nece- 
sitas el almacenamiento dinámico. Tras un tiempo de dificultades para acos- 
tumbrarte a su compañía, comprobarás que los punteros son amigos verdade- 
ros. Algunas operaciones, como la supresión de un elemento de una cabeza 
de lista, se hacen de verdad en forma mucho más fácil y eficiente usando el 
almacenamiento dinámico que con los arrays o matrices ordinarios. 
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Una biblioteca es «pensamiento» conservado en un frigorífico. 


LORD SAMUEL 
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Bibliotecas 


Este capítulo podría ser el más corto de todos los tiempos. Podría estar 
formado por esta única frase: “En PASCAL no existen bibliotecas””. Sin em- 
bargo, vale la pena decir algo más. 

Una de las grandes ventajas del PASCAL es la facilidad con que permite 
preparar procedimientos y funciones autónomos, o autocontenidos, que se pue- 
den usar libremente en cualquier programa, sea tuyo o ajeno. Un buen pro- 
gramador debe, en cooperación con sus colegas, crear una biblioteca de tales 
programas y ponerla a la disposición de toda la comunidad de usuarios. La 
biblioteca podría almacenarse o conservarse en un disco. 

Es bastante sorprendente, por tanto, que el informe PASCAL no hable de 
bibliotecas. Ahora trataremos de explicar por qué. En bien de la concisión, 
hablaremos sólo de procedimientos, pero lo que digamos es aplicable igual- 
mente a las funciones de biblioteca. 


Bibliotecas o códigos fuente y objeto 


El primer punto que se ha de exponer es que las bibliotecas se pueden po- 
ner a disposición de los usuarios en forma fuente o en forma objeto. Como 
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hemos dicho anteriormente, un compilador convierte el programa que le en- 
tregamos, el programa fuente, en una forma binaria interna que los escritores 
de compiladores llaman código objeto. (Para esos compiladores que ejecutan 
los programas en forma muy lenta, “código abyecto”” sería un nombre más 
adecuado.) 

Si tienes un procedimiento de biblioteca largo, cuya compilación ocupe va- 
rios minutos, parece atractivo el convertirle en código objeto de una vez por 
todas, y poner a disposición de los usuarios de la biblioteca este código objeto, 
en lugar del programa fuente. En este caso, los programas de usuario se cons- 
truyen con la ayuda de un programa del sistema al que algunas veces se llama 
un enlazador (linker). El enlazador une el programa objeto del usuario con 
el código objeto de cualesquiera procedimientos de biblioteca que necesite. En- 
tonces, el programa resultante está listo para su ejecución. 

Este método parece atractivo y, realmente, es muy utilizado. Es muy posi- 
ble que lo hayas empleado en un sistema BASIC. Sin embargo, adolece de dos 
desventajas. La primera es que los programas enlazadores o linker, a pesar de 
su tarea aparentemente sencilla, son con mucha frecuencia lentos y complica- 
dos. Esta desventaja se potencia aún más como consecuencia de uno de los 
méritos del PASCAL: como este lenguaje ha sido diseñado teniendo presentes 
los problemas de la compilación, los compiladores son relativamente rápidos. 
(Desde luego, el tuyo puede ser una de las excepciones.) En consecuencia, mu- 
chas veces es más rápido compilar de nuevo un procedimiento que incurrir en 
la pérdida de tiempo adicional que supone el aplicar el enlazador a su código 
objeto. 

La segunda desventaja que tiene el enlace con procedimientos de código 
objeto es más fundamental: desconcertamos y molestamos a Perkins. Una de 
las aportaciones de Perkins al PASCAL es que se ocupa de verificar, en todas 
las llamadas que se hagan a procedimientos, que los argumentos y los paráme- 
tros concuerden en cuanto a número, tipo de datos, etc. Lo hace de una vez 
para siempre en el momento de la compilación, de modo que en el de la ejecu- 
ción tengas una cómoda sensación de seguridad, pero sin ninguna carga adi- 
cional de comprobaciones. Toda esta estrategia se basa en la declaración de 
los procedimientos en el programa que los utiliza, de modo que Perkins puede 
echar un vistazo al encabezamiento de los mismos y compararle con las llama- 
das. Si existe una posibilidad de compilar por separado los procedimienos y 
el programa que los usa, puede perderse la seguridad. 

Tal vez no sea obvia inmediatamente la razón para esta falta de seguridad. 
La mayor parte de los sistemas PASCAL que contienen ampliaciones o exten- 
siones para soportar bibliotecas de código objeto, exigen, en efecto, que el pro- 
grama que utilice la biblioteca —el programa llamador— declare un encabeza- 
miento por cada procedimiento de la biblioteca utilizado. En lugar del cuerpo 
de tal procedimiento, se escribe la palabra externo (o análoga). Así, si un pro- 
grama llamador hace uso del procedimiento de biblioteca útil, que toma un 
parámetro real, necesitaría contener la declaración 


procedure útil(x: real); extern; 


Entonces, efectivamente, Perkins podrá comprobar que todas las llamadas a 
útil tengan los argumentos apropiados. 

La falta de seguridad surge porque el procedimiento contenido efectivamente 
en la biblioteca puede no coincidir con su descripción dada en el programa lla- 
mador. El verdadero procedimiento útil puede, por ejemplo, tomar un pará- 
metro matricial. El resultado es que el programa se hace un lío. Si tienes suerte, 
producirá rápidamente un mensaje de error; si no la tienes, puede volverse lo- 
co y corromper todo tu sistema. 

Ahora bien, si deliberadamente has declarado que un procedimiento es al- 
go distinto de lo que es en realidad, con la finalidad de hacer trucos como los 
que haces en los registros con las uniones indiscriminadas, te merecerás lo que 
te pase. Sin embargo, es fácil declarar mal un procedimiento en forma com- 
pletamente accidental, y en este caso el castigo puede ser mucho mayor que 
el delito. 


Bibliotecas de códigos objeto con seguridad 


Algunos sistemas PASCAL realizan la hazaña de dotar de una seguridad 
completa a las bibliotecas de códigos objeto. Para ello, hay que agrupar entre 
sí, formando una unidad: 


e La declaración que necesita un programa llamador. 


e El código objeto del procedimiento. 


Ambas partes se crean automáticamente a partir del código fuente del pro- 
cedimiento, y el programa llamador no puede acceder a una de ellas sin la otra. 
Como mecanismo de un tipo más general, algunos sistemas realmente excelen- 
tes permiten agrupar en una biblioteca cualquier clase de declaraciones. Esto 
podría incluir, además de las declaraciones de procedimientos, las de constan- 
tes y de tipos. Para almacenar en una biblioteca abstracciones tales como las 
utilidades para números complejos que hemos visto en el capítulo 8, es necesa- 
rio este tipo de facilidad. 

Los sistemas PASCAL de esta naturaleza son normalmente los que funcio- 
nan con sistemas operativos diseñados pensando en el PASCAL. Aquellos PAS- 
CAL que tienen que lidiar con sistemas operativos poco cooperativos tienen 
muchas más dificultades para ofrecer seguridad. 

Si tienes un sistema PASCAL que ofrezca bibliotecas seguras de código ob- 
jeto, considérate extremadamente afortunado: sean cuales sean los demás pro- 
blemas de tu vida, gozas de la bendición de un don auténtico. 


Bibliotecas en otros lenguajes 


Puede ocurrir que, dentro de tu programa PASCAL, desees usar procedi- 
mientos escritos en otros lenguajes. La necesidad de ello puede surgir por dos 
causas. Primera, puedes tener un procedimiento existente que funcione bien, 
y no deseas tomarte el trabajo de traducirlo al PASCAL. Segunda, puede ocu- 
rrir que desees realizar alguna operación que en PASCAL sea imposible. En- 
tonces, la única forma de salvar el inconveniente es escribir en algún otro len- 
guaje, por ejemplo en ensamblador, un procedimiento para conseguir el efec- 
to deseado, y utilizar este procedimiento en tu programa PASCAL. 

Al llamar a procedimientos en lenguajes extraños, es frecuente que haya 
problemas para la representación de los tipos de datos. Puede ocurrir, por ejem- 
plo, que los distintos lenguajes almacenen los arrays o matrices en formas di- 
ferentes. Por consiguiente, los problemas de seguridad son inmensos, y el me- 
jor consejo es que, mientras sea posible, se evite el uso de procedimientos ex- 
traños al lenguaje. 

A pesar de este consejo, Bill mostró un interés poco usual en el tema. Ave- 
riguamos con gusto que había llegado incluso a escribir un programa en PAS- 
CAL, aunque cuando vimos el programa nos sentimos bastante menos impre- 
sionados. Era el siguiente: 


program x(input, output); 
procedure miprogramabasic; extern; 
begin 

miprogramabasic; 
end. 


No obstante, era un esfuerzo que indicaba voluntad, y no tuvimos valor 


para decirle que son muy pocos los sistemas que permiten la llamada de pro- 
gramas BASIC desde dentro de programas PASCAL. 


La sentencia CHAIN 


En el PASCAL estándar no existe equivalente alguno de la sentencia CHAIN 
del BASIC. Sin embargo, al igual que ocurre con las bibliotecas en código ob- 
jeto, algunos compiladores PASCAL ofrecen facilidades extra de esta natura- 
leza, con seguridad o sin ella. 
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Bibliotecas en código fuente 


Supongamos que, por las razones que sean, has decidido construir tu bi- 
blioteca en código fuente, y no en código objeto. Es indudable que no puede 
haber objeciones prácticas ni morales al uso de bibliotecas en código fuente. 
Verdaderamente, no las hay; pero, sin embargo, hay todavía muchos compila- 
dores PASCAL que no soportan esas bibliotecas. La razón es que, para man- 
tenerse dentro de un tamaño razonable, el PASCAL se esfuerza al máximo 
en no asumir las funciones de otros programas o elementos de software, tales 
como el sistema operativo o el editor. La inclusión de bibliotecas está conside- 
rada como una tarea de este software externo. 

Desgraciadamente, éste no es usualmente un enfoque ideal, y es mejor dis- 
poner dentro del programa PASCAL de una orden o comando para incluir 
en él el material procedente de bibliotecas en código fuente. Por esto es por 
lo que muchos PASCALES soportan una orden o comando tal como 


include filename; 


Si tu compilador dispone de una facilidad include, debes aprovecharla al má- 
ximo. Aunque se trata de una característica no estándar, no pone en peligro 
la portabilidad. Si necesitas trasladar tu programa a otro ordenador, siempre 
podrás construir un programa completo utilizando todos sus trozos o fragmen- 
tos introducidos con include. Es más, y para decirlo en la forma más vigorosa: 
si tienes una buena facilidad include, en contraposición con una facilidad po- 
co segura para bibliotecas en código objeto, olvídate de esta última; sólo cuando 
su necesidad se haga realmente apremiante, deberás descender al nivel del có- 
digo objeto. 
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No hay nada como una comida gratis. 


El aforismo más verdadero en 
la informática 
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Resumiendo 


El saldo 


Vamos a terminar con un breve resumen de lo que ganas y lo que pierdes 
al pasarte al PASCAL. 

La ganancia más importante, como hemos destacado todo el tiempo, es 
la legibilidad. Si un gran programa no es legible, no es nada. 

El profesor Primple nunca escribe comentario alguno en sus programas en 
PASCAL. “El PASCAL es autoexplicativo y se documenta a sí mismo””, enun- 
cia. Sin embargo, las mentes no tan privilegiadas hallan sus programas impo- 
sibles de entender, y encontrarían más fácil un programa BASIC bien comen- 
tado. Así pues, si tu programa ha de ser leído por estos mortales menos emi- 
nentes, no desprecies las ventajas de la legibilidad fundamental del PASCAL 
omitiendo los comentarios. Necesitas menos comentarios de bajo nivel que en 
BASIC (““Esto es un bucle””), pero todavía necesitarás explicar la estrategia 
de nivel más alto de tu programación. 

Cuando se consigue la legibilidad, siempre viene seguida de otras innúme- 
ras ventajas en el terreno de la corrección de los programas y de su manteni- 
miento. 


227 


Otros beneficios que produce el PASCAL son los relativos a la portabili- 
dad, la seguridad y la estructuración. 

El principal precio que hay que pagar por todo ello es tu inversión inicial 
de tiempo y paciencia. Ya has hecho un pago parcial, tal vez bastante grande, 
al haber avanzado laboriosamente hasta el final de este libro. Sin embargo, 
el “leer”” es sólo una pequeña parte en el aprendizaje de un nuevo lenguaje; 
el “hacer”? es una parte mucho más importante. 

Cuando se entra en contacto con un elemento de software nuevo, como 
cuando se conoce por primera vez a una persona, es poco probable que se pro- 
duzca una amistad inmediata con él. Inicialmente, tu nuevo conocido te pare- 
cerá raro y caprichoso, y te será difícil establecer la comunicación. La prueba 
principal de su valor llega después de varias semanas en su compañía. En algu- 
nos casos, para entonces habrás llegado a la conclusión de que es aún más raro 
y caprichoso de lo que habías pensado al principio, y de que la comunicación 
con él es todavía más difícil, en cuyo caso será el momento de decirle adiós. 
Otras veces, en cambio, comprobarás que, bajo un aspecto exterior antipático 
O poco atractivo, se ocultaba lo que ahora ha llegado a ser un amigo cordial. 

Al hacer el cambio al PASCAL, conoces nuevos editores, otros sistemas 
operativos, compiladores y depuradores o debuggers, y el tratar de hacer amistad 
con todos ellos es una considerable tarea, sean cuales sean los méritos del len- 
guaje PASCAL. A menudo resulta particularmente difícil asimilar un nuevo 
estilo para la depuración de programas. 

Al mismo tiempo que te vas acostumbrando a estos programas de sistemas, 
tienes que ir creando una comprensión más íntima del PASCAL propiamente 
dicho. 


La adaptación del estilo 


A pesar de su fracaso con el programa de la biblioteca, Bill Mudd ha escri- 
to un segundo programa PASCAL. Es como sigue: 


program CUENTAS(INPUT, OUTPUT); 
(* REM COPYRIGHT BILL MUDD, 1982 x) 


label 

10,20,30,40,50,60,70,80,90,100,110,120,130,140, 
200,210,220,230,240,250,999; 

var 

A,B,C, D, E,F,G,H,L M,N, O, P,O,R,S, T, U, V, W,X, Y,Z: REAL; 

J,K, L:!INTEGER,; (+ REM PARA USAR EN SENTENCIAS FOR +) 
ADOLAR, BDOLAR, CDOLAR, DDOLAR:CHAR; 


(x* REM ESTOS PROCEDIMIENTOS EVITAN LA CONFUSION DE 
USAR READ PARA INPUT x) 

procedure /¡NPUTN(var X:REAL);begin;read(X);end; 

procedure /NPUTS(var X:CHAR);begin;read(X);end; 

begin; 

(x* REM YO SIEMPRE PONGO ESTAS DECLARACIONES ANTE- 
RIORES AL PRINCIPIO DE TODOS MIS PROGRAMAS EN PAS- 
CAL. PUEDO VENDER ESTA VALIOSISIMA AYUDA A QUIEN LA 
DESEE POR SOLO CIEN LIBRAS x) 


10:  INPUTMN(A); 

20: if X>0 then goto 50; 

30:  WRITELN(TECLEE UN NUMERO POSITIVO”); 

40: goto 10; 

S0:  S:=0; 

60: — for K:=1 to TRUNC(X) do begin; 

70: — (* REM LEE X NUMEROS Y LOS SUMA +); 

80:  INPUTN(O); 

90: ¡if O< >99.99 then goto 130; 

100:  (* REM 99.99 SIGNIFICA DATO FINAL. PASA K A VALOR 
ALTO PARA PARAR EL BUCLE x); 

110: K:=12345; 

120: goto 140; 

130: S:=S+0; 

140: (* NEXT K x)end; 

200: WRITELN(S/X, “ES LA MEDIA DE LOS NUMEROS”), 

210: WRITELN(¿DESEA USTED CONTINUAR?”); 

220: INPUTS(ADOLAR); 

230: ¡if ADOLAR= N” then goto 999; 

240: ¡if ADOLAR< > “Y? then goto 210; 

250: goto 10; 

999: HALT, 

end. 


No sólo ha escrito un programa PASCAL, sino que ha tenido la amabili- 
dad de pasarnos el fruto de su experiencia: ““Si tenéis que programar en PAS- 
CAL, lo que os aconsejo es que pongáis labels o etiquetas para todas las lí- 
neas, de modo que, si más adelante os parece bien, siempre podáis hacer GO- 
TO a cualquiera de ellas. También sirve de ayuda al editar. He escrito un edi- 
tor especial (en BASIC, desde luego) que agrega automáticamente las labels 
o etiquetas, y también pone el punto y coma al final de cada línea. ¿Sabéis 
lo que os digo? Si uno se esfuerza, puede llegar a convertir al PASCAL en 
un lenguaje bastante majo.”” 

““Al principio tuve algunas dificultades con el Perkins ese”, continuó. “Se 
oponía a que yo cambiara el valor de K en la línea 110. Sin embargo, hace 
poco he tenido la suerte de hallar un compilador que casi no hace ninguna com- 
probación. Con él se puede alcanzar pronto la fase de ejecución del programa, 
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y entonces se puede poner manos a la tarea de conseguir que las respuestas 
salgan bien.”” 

Es estupendo ver a Bill realizar un esfuerzo tan grande, pero, desgraciada- 
mente, si vas a escribir los programas PASCAL como los BASIC, harías mu- 
cho mejor en continuar con éste. Para escribir verdaderos programas PAS- 
CAL, hay que hacer el esfuerzo preciso para dominar los conceptos nuevos. 
Entre los que más hemos destacado, figuran: 


e las sentencias de formación de bucles; 
e la estructura en bloques y las variables locales; 


e la selección de los tipos de datos de manera que el programa se adecúe 
al problema; 


e el almacenamiento dinámico. 


El dominar todo esto te llevará algún tiempo, pero el aprendizaje de con- 
ceptos nuevos y claros es realmente divertido, de modo que el tiempo pasará 
rápidamente. El tiempo empleado en dominar conceptos que son más familia- 
res, pero menos claros, como el de input/output en PASCAL, te parecerá más 
largo. 


El esfuerzo en la preparación de programas 


Incluso después de haber llegado a dominar el PASCAL, te darás cuenta 
de que las primeras fases de la preparación de los programas te llevan más tiem- 
po que con el BASIC. Tienes el trabajo adicional de declararlo todo, y, en com- 
paración con el BASIC, empleas mucho más tiempo en la localización y la co- 
rrección de los errores de sintaxis. De vez en cuando te sentirás obstaculizado, 
al impedirte el PASCAL que hagas algo que realmente desees hacer. Estas mo- 
lestias, sin embargo, no constituyen realmente un coste debido al empleo del 
PASCAL; el tiempo adicional que se invierta inicialmente en la preparación 
de un programa disciplinado, se verá más que adecuadamente compensado des- 
pués si el programa tiene cierta magnitud. 

Si tu programa es pequeño y de fácil compresión, no dudes en seguir utili- 
zando el BASIC. Muchos programadores experimentados de PASCAL utili- 
zan el BASIC para los programas pequeños, especialmente para aquellos que 
tratan de manipulación de cadenas o strings y de entrada/salida; sin embargo, 
jamás lo confesarían ante sus colegas. 


La ampliación o extensión 


Si deseas hallar más información acerca del lenguaje PASCAL y de la for- 
ma en que está implementado, un excelente punto de partida es la colección 
de artículos titulada PASCAL. El lenguaje y su implementación, editada por 
D. W. Barron (1981). Este trabajo suscita la interesante idea de que un lengua- 
je sea ““mejor que sus sucesores””. Ciertamente, existe una importante corrien- 
te de opinión según la cual, si un lenguaje está bien construido y todas sus par- 
tes encajan armoniosamente, los intentos de ampliarle o de restringirle no tie- 
nen más probabilidades de éxito que las que podría tener una nueva versión 
abreviada (o ampliada) de una sinfonía de Beethoven. 

Se han hecho muchas tentativas consistentes en tomar unas cuantas carac- 
terísticas del PASCAL y pegárselas al BASIC. Es posible que el híbrido resul- 
tante sea un lenguaje utilizable, pero decir que ofrece todas las ventajas del 
PASCAL sería pura charlatanería. 


Palabras finales 


Bill insiste en decir él la última palabra y, al parecer, ha abandonado aque- 
llos esfuerzos en el PASCAL que hemos descrito tan recientemente. 


““He probado el PASCAL””, dice, ““pero me di cuenta de que estaba 
invirtiendo demasiado tiempo en aprender el lenguaje y en conseguir que 
el compilador aceptara mis programas. Yo soy un hombre muy ocupado. 
Necesito todo este mes para conseguir que funcione el programa BASIC 
de mil líneas con el que estoy actualmente, y pienso emplear el mes que 
viene tratando de averiguar cómo funciona un gran programa BASIC 
que escribí el invierno pasado. Así que, desde luego, no dispondré de 
ningún tiempo de sobra para malgastarlo en el PASCAL.” 
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Apéndice A: 
Procedimientos 
y funciones 
incorporados 


En este libro se han mencionado la mayoría de los procedimientos y fun- 
ciones incorporados en el PASCAL. Aquí los presentamos todos reunidos en 
un mismo sitio. Es indudable que cada implementación tendrá algunas adicio- 
nes a nuestra lista, pero nosotros nos limitamos aquí a las rutinas definidas 
en el informe del PASCAL. 

Las letras que empleamos para representar argumentos indican el tipo de 
datos de los mismos en la forma siguiente: 


f significa archivo (file), 

í significa entero (integer), 

p significa puntero (pointer), 

r significa real, 

s significa un tipo definido por el usuario, o Boolean o char. 


Procedimientos 


A continuación se da una lista de los procedimientos incorporados: 


a) Concernientes a ENTRADA/SALIDA. Véase el capítulo 9 


get(f) avanza en un componente la exploración del archivo f y asig- 
na el valor del nuevo componente a fT; 

pagelf) inicia una nueva página en el archivo de texto de salida f; 

putlf) agrega o pospone ff al archivo f, 

reset(f) prepara el archivo f para su lectura, actualizando f? al valor 


del primer componente; 
rewrite(f) prepara el archivo f para la escritura, destruyendo cualquier 
versión anterior del mismo. 


Además existen los procedimientos read, readln, write y writeln, que to- 
man un número variable de argumentos. 


b) Concernientes a la asignación de espacio de almacenamiento o memoria. 
Véase el capítulo 11 


dispose(p) devuelve el espacio de memoria ocupado por la variable di- 
námica a la que apunta p; 

new(p) toma memoria prestada para una variable dinámica y esta- 
blece a p para que apunte a ella. 


c) Concernientes a las matrices compactadas. Véase el capítulo 7 


pack(au, índice, ap) compacta la matriz au dentro del ap, empezan- 
do con el elemento au[índice]; 
unpack(ap, au, índice) inverso del pack. 


Aquí ap es una matriz compactada, au es una no compactada del mismo 
tipo, e índice es un índice aceptable para estas matrices. 


Funciones 


A continuación se da una lista de funciones incorporadas. Las concernien- 
tes a la aritmética se presentaron en el capítulo 4, las relativas a entrada/sali- 
da, en el 9, y ord, pred y succ, en el 6. Las funciones odd y round se describen 
por primera vez aquí. 


a) Que producen un resultado entero (integer) 


abs(i) el valor absoluto de i; 

ord(s) el número ordinal de s en el conjunto de valores posibles de s; 
roundl(r) el entero más próximo a r; 

sqr(i) el cuadrado de i; 

trunc(r) el entero que se obtiene suprimiendo la parte fraccionaria de r. 


b) Que producen un resultado Booleano 


eof(f) true si f está situado en el final del archivo; 
eoln(f) true si f está situado al final de la línea; 
oddl(i) true si ¡ es impar. 


Cc) Que producen un resultado real 


abs(r) el valor absoluto de r; 
arctan(r) el arcotangente de r; 
cos(r) el coseno de r; 

exp(r) e elevado a la potencia r; 
In(r) el logaritmo natural de r; 
sin(r) el seno de r; 

sqr(r) el cuadrado de r; 

sqrt(r) la raíz cuadrada de r; 


d) Que producen como resultado un carácter 
chr(i) el carácter cuyo número ordinal es ¡. 


e) Que producen el mismo tipo del argumento 


pred(s) el predecesor de s; 
succ(s) el sucesor de s. 


Las funciones trigonométricas (arctan, cos, sin) funcionan en radianes. 


Apéndice Bb: 
Sumario 
del PASCAL 


El objeto de este Apéndice consiste en presentar un programa completo que 
ilustre la mayoría de las características del PASCAL. Es un complemento al 
Apéndice C, que contiene una especificación sintáctica mucho más precisa. 

Si estás escribiendo programas en PASCAL, este Apéndice te podrá ser útil 
en dos formas. En primer lugar, te podrá ser útil como consulta o referencia 
rápida si se te han olvidado algunos detalles sintácticos. En segundo lugar, si 
repasas el programa línea por línea, te podrá recordar alguna característica po- 
tente del PASCAL que no hayas estado usando. Sin embargo, no trates de ave- 
riguar lo que hace este programa: no hace nada sensato en absoluto; es simple- 
mente un catálogo de ejemplos aislados. 

Para mantener este ejemplo de programa razonablemente corto, hemos omi- 
tido algunos de los conceptos más caprichosos o lujosos, como el with, los re- 
gistros con variantes y los archivos binarios. 


(xr A od od ole a ad ode ale a ad ode ale ale ad ade ale ale ad ale ale 


Encabezamiento del programa 
EEE EEE EEE EEE EEE EEE EEES *) 


program xxx(input, output); 
(x o, si utiliza archivos externos 


program xxx(f1,/2,input, output); 
*) 
(dalla ak 


Declaraciones de etiquetas o labels, constantes, tipos y variables 
A ode ode oe ole ode ade a ole ode ode a ole ode ade ole ode ole ae ole ole ode ade ale ole ode ale ole ode a ole ode ode a ale ole ad ale ode ade a ale ode ad ale ale *) 


label 
999,15; 


const 
tamañogrupo = 20; 


peculiar = “x?; 
pi = 3.14159; 


type 
quesos = (Stilton, Cheddar, Cheshire, Wensleydale); (+ tipo definido 
por el usuario x) 
porcentaje = 0..100; (* un tipo de subrango x) 
tablaquesos = set of quesos; 
array!l = array [1..tamañogrupo, quesos] of real; (x* el segundo sub- 
índice es un queso x) 
array2 = packed array [1..6] of char; (x* una cadena o string x) 
array3 = array [porcentaje] of Boolean; 
petición = 
record 
puntuación: porcentaje; 
correcto: Boolean; 
end; 
listapunt =1colección; (* un puntero x*) 
colección = 
record” 
campol: real; 
campo2: integer; 
campoarray: array [1..10] of quesos; 
siguiente: listapunt 
end; 
var 
índice, vint: integer; 
vreall, vreal2: real; 
estálloviendo: Boolean; (* puede tomar los valores true o false *) 
miinicial: char; (« un solo carácter x) 
mejorqueso: quesos; 
mipuntuación: porcentaje; 
mielección, suelección: tablaquesos; 
al: arrayl; 
respuesta: array2; 
ocurre: array3; 
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( 


apuntdecabeza: listapunt; 
resultexamen: petición; 
f1, f2: text; (x archivos de texto x«) 


A ad ad ale a ad ale ale ad ad ode ale al ad ade ale a ad ade ale ad a ad ade ale a ad ale ale al ale ale 


Declaraciones de funciones y procedimientos 
EEES) 


function (paraml: integer; param2: quesos): real; (« El resultado de la 
función es real +) 


var 
milocall: quesos; 
milocal2: integer; 
begin 
milocal2: = paraml div 3; 
for milocall: =Stilton to param2 do 
milocal2: = paraml1 x« (milocal2 + 1); 
f.=milocal2/6; (* asigna el resultado de la función +) 


end; (x f x) 

procedure puestacero (var x: integer); 

(x* Este procedimiento pone simplemente a su parámetro en cero. 
No tiene ninguna declaración local x) 

begin 
x:=0; 

end; (* puestacero +) 

begin(* programa principal  x) 

(x Adol a ad od ale e ad ad ade ole a ad ode ale al ade ale ale ale ad ade ale ale ad ade ale ale ad ade ale ale e ad ale ale o 


Ejemplos de constantes, expresiones y sentencias 
Ao olaaa lalalala jdjdjojojaialaloldlololok a) 


(x 1: asignaciones en las que se muestran constantes v expresiones x) 


vreall:= 3.577E-2; (x* una constante real x) 

vint:= vint mod 3 — vint div tamañogrupo, (* operadores espe- 
ciales de integer 
*) 

estálloviendo: = true; 

miinicial: = “p”; 

mejorqueso: = Stilton; 

suselección: = [Cheshire]; (x* un constructor de conjuntos x) 

miselección: = [Stilton.. Wensleydale]; 

suselección: = suselección + [mejorqueso]; (x* una unión de con- 

juntos +) 
apuntdecabeza: = il; 


(x* 2: 


(x 3: 


po 


ES 


(* S: 


condicionales x) 


if estálloviendo then 
vint:= vint+ 1; 
if (apuntdecabeza= nil) or not (Cheddar in miselección) then 
begin (* una sentencia compuesta x) 
vreal2: = cos(vreall ); 
if vreall > vreal2 then (x* un if anidado x) 
vreall: = vreall + 1; 
end else 
vreall:= -vreal2; 
case miinicial of 
writeln(*¿Te llamas Pedro?”); 
w>b”: 
writeln(*¿Te llamas William o Bill?” y; 
peculiar: 
begin 
writeln (No conozco ningún nombre que empiece así.”); 
writeln (¿Estás seguro de que está bien?”); 
end; 
end; 


llamadas de procedimientos y de funciones x) 


puestacero(vint); 
vreall: =f(6, mejorqueso)/3.9; 


: referencias a arrays, registros y punteros x) 


al[6, Cheddar]:= pi; 

respuesta: = “abcdef”; (* constante de cadena o string x) 

ocurre [mipuntuación]: = false; 

resultexamen.puntuación: = 100; 

resultexamen.correct: = (resultexamen.puntuación < 62)and ocurre 
[resultexamen.puntuación]; 

new(apuntdecabeza); 

apuntdecabeza!l.campol:= 6; 

apuntdecabeza! .campodearray[4]: = Stilton; 

disposelapuntdecabeza); 


bucles x) 


for índice: = 1 to tamañogrupo do 
al[índice, Cheddar]:= 0.12; 

for índice: = vint + 4 downto 2 do 
respuesta[índice + 1]: = respuesta[índice]; 

for mejorqueso: = Stilton to Wensleydale do 
al[vint + 1, mejorqueso]: =1ES5; 
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(x* 6: 


(7: 


índice: = 10; (x* frecuentemente, un while va precedido de iniciali- 
zación x) 
while ocurre[índice] and (índice < 40) do 
índice: = índice + 2; 
mejorqueso: = Stilton; (+ un repeat va frecuentemente precedido 
de inicialización x+) 
repeat 
mejorqueso: = succ(mejorqueso)); 
mipuntuación: mipuntuación + 1; 
until mejorqueso in suselección « miselección + [Wensleydale]; 


entrada/salida +) 


read(mipuntuación); 

readIn(mipuntuación, vreall, vreal2); 

write(*La respuesta es”); 

writeln(respuesta, “y mipuntuación es”, mipuntuación:3); 
reset(f1); 

rewrite(f2); 

read(fl, vreal1l); (x* entrada desde un archivo x) 

writeln(f2, respuesta, estálloviendo), (x* salida a un archivo x) 


sentencias goto x) 


(x* Yo he suprimido esta parte. 
Profesor Marcus d*A. Primple, Ph.d. +) 


(* Estas son las etiquetas o labels que no han llegado a usarse +) 


999: 
15: 
end. 


(x 


(* xxx x*) 
PS 
goto 999; 
Bill Mudd, B.Sc.(suspendido) x) 


Apéndice C: 
Diagramas 
de sintaxis 


Explicación 


Los diagramas de sintaxis constituyen una forma gráfica muy cómoda y 
conveniente para definir la sintaxis precisa de un lenguaje de programación. 
Este Apéndice contiene diagramas de sintaxis para el PASCAL basados en los 
diagramas de Grogono (1980)*. Por cierto, es posible que desees consultar es- 
te libro de Grogono. Da una descripción del PASCAL en un nivel mucho más 
detallado que el de éste. 

La regla para la utilización de un diagrama de sintaxis es sencilla: si es po- 
sible formar cierto conjunto de símbolos siguiendo las flechas del diagrama, 
ese conjunto de símbolos será PASCAL sintácticamente correcto; si no se puede 
formar, no lo es. Los símbolos contenidos en las cajas o recuadros especifican 
los elementos constituyentes del programa. Los nombres que aparecen en mi- 
núsculas, pero no negritas, como ““bloque”” o “identificador”? —siempre apa- 
recen en cajas rectangulares—, se refieren a elementos constituyentes definidos 


* Grogono, Programming in Pascal, O 1978, Addison - Wesley, Reading, Massachusetts, pp. 324-33. 
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66,> 


en otros diagramas de sintaxis; todo lo demás, por ejemplo “program” o “*;””, 
especifica símbolos que se pueden usar en la construcción de un programa. To- 
maremos como ejemplo el primer diagrama de sintaxis. Se reproduce a conti- 
nuación para mayor comodidad. 


El nombre que hay a la izquierda del diagrama nos dice lo que éste define. 
Así, el diagrama que aparece más arriba es el más fundamental de todos, por- 
que define lo que es un “*“programa””. Tomando este diagrama y siguiendo las 
flechas desde el principio, vemos que un programa consta del símbolo program 
seguido por un identificador, seguido por un **(”” y otro identificador. Enton- 
ces podemos tomar cualquiera de dos ramas. Una consiste en seguir recto, 
pasando por **)””, **;””, “bloque” y **.”” Esto nos dice que un posible progra- 


ma es 
program < identificador > (< identificador > );, < bloque > . 


en el que la notación < identificador > significa cualquier cosa que encaje en 
el diagrama de sintaxis ““identificador””, y lo mismo se puede decir de 
< bloque >. 

Si, en lugar de seguir la rama recta o directa, realizamos un bucle hacia 
atrás, terminamos con 


program < identificador > (< identificador > ), < identificador > 


En este punto, nos encontramos de nuevo con la misma decisión. Podemos 
hacer otro bucle hacia atrás e incluir otra coma y otro identificador, o seguir 
rectos hasta el final. El significado general es que podemos tener, dentro de 
los paréntesis, tantos identificadores como queramos, separados por comas. 

La ventaja de esta notación es que, a diferencia de las explicaciones verba- 
les dadas en este libro, es absolutamente precisa. Sabes, por ejemplo, que ha 
de haber por lo menos un identificador dentro de los paréntesis. No se puede 
escribir 


program XXX; 


sin paréntesis alguno. Por otra parte, si miras la definición de una lista de pa- 
rámetros para un procedimiento —ve el diagrama de sintaxis titulado “lista 
de parámetros””—, verás que en este caso se puede omitir la lista entre parénte- 
sis (siguiendo la línea superior de derivación). 

Una vez que hemos hallado la sintaxis general de un programa, tenemos 
que rellenar las definiciones de ““identificador”” y de ““bloque””. La definición 
de *““bloque”” es especialmente interesante, y puede dar respuesta a muchas pre- 
guntas. Por ejemplo, la respuesta a ““¿Es posible omitir la sección var?”” es 


afirmativa, pero la de la pregunta “¿Puede haber dos secciones var?”” no lo es. 
(Todas las líneas son como calles de sentido único, y está prohibido el giro 
de 180 grados.) 

Finalmente, si vamos hacia el final de los diagramas de sintaxis podemos 
encontrar que un indentificador es una letra seguida por un número arbitrario 
de letras o cifras. Los dos últimos diagramas definen lo que son letras y cifras, 
pero encierran pocas sorpresas. (De hecho, la mayoría de los Pascales sopor- 
tan letras minúsculas, además de las mayúsculas.) 


Limitaciones 


Obsérvese que estos diagramas, aunque tienen un enorme valor, no lo defi- 
nen todo. No dicen nada acerca del espaciado, los cambios de línea ni los co- 
mentarios, ni especifican la regla según la cual tenemos que declarar todos los 
identificadores que usemos. Son cuestiones que no se prestan bien a la nota- 
ción gráfica, y es necesario definirlas en alguna otra forma. Normalmente, se 
definen en forma verbal, como lo hemos hecho nosotros en este libro. 
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Diagramas de sintaxis del PASCAL estándar 


programa identificador identificador 


bloque MK: 


() 
() 
A 


constante 


ll MN A | identificador S tipo 
lista de parámetros (5) 


lista de parámetros identificador de tipo 


identificador 


E sentencia 1 (end) 
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de parametros 


(function ) identificador LEE (5) —identificador de tipo] 


lista de parámetros 


identificadorde tipo 


encabezamiento 


tipo: 


(1) — identificador de tipo 


pd 


lista de campos 


constante 


OA 


tipo simple 


identificador 


=3)—0— 


constante 
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sentencia 1 entero sin signo A 7 


variable 


expresión 


identificador delfunción 


identificador de-procedimiento 


expresión. 


identificador de-procedimiento] 


sentencia 


dla 


sentencia sentencia 


sentencia 5 
expresión 


sentencia 


sentencia 
ME===0> 


(>) sentencia 
a 
O 


sentencia: 


entero sin signo 
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expresión 


expresión simple 


expresión simple 


término 


factor 


identificador de función 

Ep 
O 0 
Mi OA Y 


identificador de variable 
E | identificador de campo El 
2 identificador de campo JE 
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identificador de constante 
número sin signo 
e 


constante 


constante sin signo 


identificador de constante 
número sin signo 


“número sin signo 


entero sin signo 


identificador 


MINI nada 
ATI 


Diagramas de sintaxis del TURBO PASCAL 


bloque 


(label) 3 identificador de etiqueta Ñ 


constante 


ñ identificador E 
Ñ identificador 


absolute 


identificador 


overlay 


procedimiento 


procedimiento 


constante identificador deconstante 


número sin signo 


caracter 


entero sin signo 
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expresion 


expresión simple 


expresión simple 


factor 


. constante sin signo 
variable 
identificador de función 


lista de campo 


. identificador 


identificador de tipo 


lista de campo 


identificador 


identificador de etiqueta 


cadena o 'string' 


lista de parámetros 


identificador de tipo 


programa 


Corogram >)» identificador] 


procedimiento 


lista de parámetros 


function lista de parámetros 


identificador de tipo) 


expresión simple 


término 


tipo simple 


. identificador de tipo 


identificador 


constante constante 


sentencia 


identificador de etiqueta (+) 
' 


identificador 
de función 


identificador 
de procedimiento 


expresión 


expresión 


sentencia inline 


expresión 


sentencia 


sentencia 


expresión 


sentencia 


sentencia 


sentencia 
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término 


MRIITZTZ, 


. tipo simple 


tipo 


constante sin signo 


me identificador de constante 
número sin signo 


caracter 


entero sin signo 


entero sin signo 


dígito hexadecimal 


número sin signo 


(E) AN entero sin signo 


variable 


identificador de variable 


identi 


cador de campo 


sentencia inline 
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expresión inline 


termino inline 


érmino inline 


Ma 


identificador 


término inline 
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espacio de memoria, 94, 
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función, 83. 
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GOSUB, 83. 
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hardware, 35. 

heap, 200. 
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herramientas, 105-6. 
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howout, 68, 78. 


identificador, 64-5, 68. 
de campo, 141. 
IF, 71-3. 
IF END, 165. 
if, sentencia, 71-3, 75. 
implementación del Pascal, 30, 193. 
indicador (véase puntero electrónico). 
input, 157-8, 164. 
in, 189. 
include, 225. 
incorporada, función, 68, 83. 
incorporado, procedimiento, 90. 
indexado, tipo de datos, 120. 
índice de array o matriz (véase subíndi- 
ce). 
información, ocultación de, 91, 147. 
informe Pascal, 31, 104, 147, 149, 221. 
inicialización (de archivos), 164. 
INPUT, 23, 79, 156. 
input/output, 86, 157-64, 173-7. 
INT, 69, 89. 
integer, 20-1, 65, 68, 79, 120, 157. 
interactivo, 25, 46. 
entrada/salida, 173-7. 
lenguaje, 59. 
intérprete, 32. 
intersección de conjuntos, 188. 
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lista, 209, 218. 
listado, 58. 
llaves, 64. 
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ámbito, 92. 
declaración, 90, 92-3. 
manual, 104, 135, 163, 182. 
rutina, 91. 


tiempo de vida, 94-S. 
variable, 94-97, 100-1. 
LOG, 69. 
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estado de, 52. 

lenguaje de, 48, 50. 
mantenimiento, 34-5, 39, 97. 
MAT, 125. 
matriz (véase array). 
máximo común divisor, 83. 
maxint, 67, 69. 
mayúsculas, letras, 17-8. 
memoria, 94. 

tamaño de la, 33. 
microordenador, 45. 
minúsculas, letras, 17-8. 
mod, 70. 
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multilínea, función, 83. 
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objetivos del Pascal, 29. 
ON, 77. 
operador, 20, 110, 114, 187. 
OPTIONBASE, 79. 
or, 188. 
or, 110. 
ord, 115. 
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de valores, 114. 
output, 157-8, 164. 


packed, 131. 
parámetro, 85-6, 166. 
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matricial, 130. 
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de variable, 67, 104. 
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prompts, 174. 
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puntero, 200-1. 

puntero adicional, 217. 
puntero electrónico, 55. 
puntero errante, 209. 

punto de exploración, 54. 
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RANDOMIZE, 79. 
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read, 23, 157, 158, 162, 172. 
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readcubed (leecubo), 88, 97. 
readln, 170-1. 

real, 20, 65, 69, 79, 157. 
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refinamiento progresivo, 91. 
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SIN, 69. 
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THEN, 71. 
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tiempo de ejecución, 33. 
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tipo definido por el usuario, 113-4, 185-6. 
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usuario). 

tipo estructurado (véase registro). 

tracing, 59. 

traducción de conceptos, 63. 
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trunc, 69-70. 

type, 66, 68, 80, 122, 153. 


unión de conjuntos, 188. 
unión indiscriminada, 152. 
unpack, 132. 

USING, 177. 

útiles (véase herramientas). 


vacío, conjunto, 186. 
var, 66, 68, 80, 131, 156, 161. 
variable, 20. 
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dinámica, 206-8. 

ordinaria, 200. 
variaciones en Basic y en Pascal, 31. 
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ventajas del Pascal, 29-30, 227-8. 
ventana en un archivo, 162-3, 172, 205. 
verificación, 39, 193. 


Welsh, 153. 
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with, sentencia, 147-8. 
write, 157, 162. 

writeln, 24, 90, 170-1. 
writeonly, 159. 


zorro, 102. 


El PASCAL es uno de los lenguajes más aptos para el desarrollo de 
aplicaciones profesionales y para el trabajo tanto con pequeños 
microordenadores como con grandes sistemas. 


PASCAL A PARTIR DEL BASIC está escrito para el programador 
razonablemente competente en BASIC, que no necesita que le expliquen 
conceptos elementales, sino que le ayuden a adaptar su forma de pensar 
desde el BASIC al PASCAL. 


Este libro, por tanto: 


— Enseña a pensar y programar en PASCAL, aprovechando los 
conocimientos actuales de programación. 

— Desarrolla las ventajas de trabajar en un lenguaje estructurado. 

— Aclara los conceptos (sistema operativo, editor, etc.) en el entorno 
PASCAL. 

— Muestra cómo se resuelven en PASCAL problemas difíciles o 
engorrosos de analizar en BASIC. 

— Contiene, además, los diagramas de sintaxis del PASCAL estándar y de una 
de las versiones más difundidas: el TURBO PASCAL. 


PASCAL A PARTIR DEL BASIC posee un eficaz planteamiento didáctico 
y está escrito en un tono ligero, que hace divertida su lectura, lo que le 
convierte en un libro idóneo para iniciarse en la programación en 
PASCAL. 
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